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Abstract 


When  Roger  Needham  and  Miehael  Sehroeder  first  introdueed  a  seemingly  seeure 
protoeol  [24],  it  took  over  18  years  to  diseover  that  even  with  the  most  seeure  eneryption, 
the  eonversations  using  this  protoeol  were  still  subjeet  to  penetration.  To  date,  there  is 
still  no  one  protoeol  that  is  aeeepted  for  universal  use.  Beeause  of  this,  analysis  of  the 
protoeol  outside  the  eneryption  is  beeoming  more  important.  Reeent  work  by  Joshua 
Guttman  and  others  [9]  have  identified  several  properties  that  good  protoeols  often 
exhibit.  Termed  “Authentieation  Tests”,  these  properties  have  been  very  useful  in 
examining  protoeols.  The  purpose  of  this  researeh  is  to  automate  these  tests  and  thus 
help  expedite  the  analysis  of  both  existing  and  future  protoeols. 

The  sueeess  of  this  researeh  is  shown  through  rapid  analysis  of  numerous  protoeols  for 
the  existenee  of  authentieation  tests.  The  result  of  this  is  that  an  analyst  is  now  able  to 
aseertain  in  near  real-time  whether  or  not  a  proposed  protoeol  is  of  a  sound  design  or 
whether  an  existing  protoeol  may  eontain  previously  unknown  weaknesses.  The  other 
aehievement  of  this  researeh  is  the  generality  of  the  input  proeess  involved.  Although 
there  exist  other  protoeol  analyzers,  their  use  is  limited  primarily  due  to  their  eomplexity 
of  use.  With  the  tool  generated  here,  an  analyst  needs  only  to  enter  their  protoeol  into  a 
standard  text  file;  and  almost  immediately,  the  analyzer  determines  the  existenee  of  the 
authentieation  tests. 


XI 


AUTOMATING  SECURITY  PROTOCOL  ANALYSIS 


I.  Introduction 

1.1  Background 

When  Roger  Needham  and  Miehael  Sehroeder  first  introdueed  a  seemingly  seeure 
protoeol  [24],  it  took  over  18  years  to  diseover  that  even  with  the  most  seeure  eneryption, 
the  eonversations  using  this  protoeol  were  still  subjeet  to  penetration  [9].  To  date,  there  is 
still  no  one  protoeol  that  is  aeeepted  for  universal  use.  Beeause  of  this,  analysis  of  the 
protoeol  outside  the  eneryption  is  beeoming  more  important.  Reeent  work  by  Joshua 
Guttman  and  others  [5]  has  identified  several  properties  that  good  protoeols  often  exhibit. 
Termed  “Authentieation  Tests”,  these  properties  have  been  very  useful  in  examining 
protoeols.  The  purpose  of  this  researeh  is  to  automate  these  tests  and  thus  help  expedite 
the  analysis  of  both  existing  and  future  protoeols. 

1.2  Problem  Statement 

Numerous  seeurity  protoeols  have  been  proposed  [29].  They  utilize  both 
asymmetrie  and  symmetrie  eryptography  and  employ  eharaeteristies  sueh  as  trusted  and 
non-trusted  third  parties.  Chapter  2  eovers  these  eoneepts  in  great  detail.  The  problem  is 
that  analysis  of  these  protoeols  is  normally  done  either  through  tedious  pen  and  paper 
proofs  or  by  realizing  weaknesses  after  the  faet.  This  researeh  is  intended  to  reduee  the 
burdensome  task  of  evaluating  protoeols  from  a  theoretieal  pen-and-paper  method  to  a 
more  automated  method  that  ineorporates  teehniques  understood  to  prove  eertain 
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correctness  properties  of  a  protocol.  Although  there  are  other  methods  to  evaluate 
protocols,  this  research  focuses  on  the  methods  developed  by  Guttman  et  al  [5]. 

1.3  Summary  of  Results 

The  Security  Protocol  Analyzer  (SPA)  successfully  shows  that  automated  tools  can  be 
highly  valuable  in  the  performance  of  protocol  analysis.  In  particular,  the  SPA  is  able  to 
determine  when  and  where  outgoing,  incoming  and  unsolicited  tests  occur  within  a 
protocol  run.  Using  string  comparisons  vice  type  comparisons  requires  specific  values  be 
given  and  does  limit  the  application  to  analysis  based  on  completed  static  runs.  However, 
putting  together  numerous  protocols  in  generic  text  files  proves  much  easier  than 
individual  protocol  development  as  noted  in  other  protocol  analyzers  [11,  27].  It  also 
allows  for  much  quicker  analysis  of  the  protocol  because  it  does  not  have  to  dynamically 
create  a  search  tree;  instead  it  only  examines  the  post-run  state  of  the  protocol  as  entered 
in  the  input  text  file.  The  SPA  takes  any  protocol  as  input  in  a  standard  text  file  and 
generates  accurate  output  that  shows  occurrences  of  authentication  tests.  Detecting 
authentication  tests  is  done  in  very  short  time. 

1.4  Thesis  Overview 

The  remainder  of  this  thesis  consists  of  four  chapters. 

•  Chapter  2  -  This  chapter  is  intended  to  give  the  reader  an  understanding  of  the 
theoretical  aspects  of  what  this  thesis  intends  to  accomplish.  This  chapter  focuses 
primarily  on  background  literature  and  other  work  done  in  the  field  of  protocol 
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analysis.  It  introduces  concepts  such  as  authentication  tests,  test  components  and 
different  types  of  encryption  methods. 

•  Chapter  3  -  This  chapter  lays  out  how  the  protocol  analysis  is  accomplished.  It 
describes  the  inner  workings  of  an  automated  analysis  tool  developed  specifically 
for  this  research  and  gives  the  reader  an  understanding  of  how  the  results  of  the 
protocol  analysis  tool  are  to  be  interpreted. 

•  Chapter  4  -  In  this  chapter,  numerous  protocols  are  executed  using  the  analysis 
tool.  The  output  is  described  and  the  importance  of  certain  functionality,  in 
relation  to  the  tool,  is  laid  out  for  the  reader. 

•  Chapter  5  -This  is  the  summary  chapter.  Here,  the  determination  about  the 
effectiveness  of  the  tool  is  given.  It  also  lays  out  the  groundwork  as  to  where 
future  work  in  the  field  of  protocol  analysis  should  go. 
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II.  Literature  Review 


2,1  Chapter  Overview 

This  chapter’s  purpose  is  to  give  the  reader  a  basic  understanding  of  strand  spaees  and 
authentication  tests.  First,  an  introduction  into  the  basie  forms  of  encryption,  symmetric 
and  asymmetric,  is  given.  This  is  neeessary  to  ensure  the  reader  understands  basie 
eryptographic  principles  that  are  discussed  throughout  this  ehapter.  Next,  a  brief 
introduetion  of  what  strand  spaces  are  and  how  they  are  a  means  of  representing 
protocols  within  the  context  of  graph  theory  is  given.  Particularly,  this  chapter  shows 
how  strand  spaces  are  used  to  model  eurrent  protocols,  such  as  Needham-Schroeder- 
Lowe  [9]  and  Kerberos  [13].  It  also  introduees  the  various  authentication  tests,  which  are 
derived  from  the  theory  of  strand  spaces.  Authentieation  tests  are  a  means  of  ensuring  a 
protocol  is  designed  well  enough  to  withstand  common  capabilities  of  penetrators,  such 
as  those  represented  in  the  Dolev-Yao  threat  model  [26]. 

Next,  this  ehapter  gives  a  brief  introduction  into  automated  modeling  tools  that 
represent  potential  candidates  for  automating  the  tests.  The  purpose  of  automating  strand 
space  analysis  is  to  show  whether  or  not  potential  weaknesses  exist  within  a  given 
protoeol.  If  successful,  this  approaeh  can  provide  a  method  for  alleviating  the  tedium  and 
inaccuracy  associated  with  pen-and-paper  proofs.  Finally,  related  work  in  the  field  of 
strand  space  automation  is  discussed  and  their  general  results  summarized. 
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2,2  Symmetric/ Asymmetric  Cryptography 

A  brief  review  of  symmetrie/asymmetrie  eryptography  is  warranted  sinee  there  is 
frequent  mention  of  ‘keys’  belonging  to  different  parties  throughout  the  remainder  of  this 
thesis. 

Symmetric  Cryptography 

With  the  advent  of  the  Caesar  eipher  over  3000  years  ago,  symmetrie  eryptography 
was  established  as  the  first  form  of  eneryption.  It  is  the  use  of  a  single  key  to  perform 
both  eneryption  and  deeryption  of  messages.  The  eoneept  works  as  follows: 

If  Bob  wants  to  send  Aliee  a  message,  they  have  an  agreed-upon  key,  whieh  they  will 
use  for  eneryption/deeryption  purposes.  This  key  is  most  likely  a  mathematieally 
generated  prime  number,  whieh  when  applied  to  an  algorithm  will  generate  eipher  text 
(the  enerypted  message).  Aliee  or  Bob  ean  then  take  the  eipher  text,  along  with  the  same 
key,  plug  it  into  the  same  algorithm  and  generate  the  original  plain  text  (the  unenerypted 
message).  Symmetrie  eryptography  has  the  advantage  of  requiring  only  one  key  for  both 
eneryption  and  deeryption,  but  if  eompromised,  all  messages  enerypted  with  that  one  key 
are  now  in  danger  of  being  read  by  unintended  parties! 

Asymmetric  Cryptography 

Asymmetric  encryption  utilizes  two  keys,  a  private  and  public  key  to  encrypt/decrypt 
a  message.  The  public  key  is  the  receiver’s  key  that  is  freely  made  available  to  all 
potential  senders.  The  private  key  is  the  key  owned  by  the  receiver  that  is  never  shown  to 
anyone  else.  In  this  case,  Alice  has  a  private  key,  which  only  Alice  knows,  and  Alice  has 
a  public  key,  which  is  available  to  anyone.  Similarly,  users  will  entrust  their  public  key 
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to  Alice  and  keep  their  private  key  to  themselves.  Because  Alice  has  another  user’s 
publie  key,  Aliee  ean  encrypt  a  message  with  that  publie  key.  Once  the  message  is  sent, 
only  the  owner  of  the  corresponding  private  key  can  decrypt  it.  Asymmetric 
cryptography  has  the  advantage  of  guaranteeing  that  only  the  intended  recipient  of  a 
message  ean  read  that  message,  and  does  not  require  sharing  private  keys  with  anyone. 
(This  assumes  one’s  private  key  is  not  compromised.)  However,  asymmetrie  keys  are 
normally  mathematically  larger  than  symmetrie  keys  so  it  is  quite  common  for 
asymmetric  cryptography  simply  to  be  used  to  encrypt  symmetric  keys  that  are 
distributed  to  intended  recipients.  Another  more  reeent  use  for  asymmetric  keys  is  digital 
signing.  By  enerypting  only  a  portion  of  the  message  (e.g.  hash  of  the  message)  with  my 
private  key,  then  enelosing  the  total  message  in  a  symmetric  key,  I  guarantee  non¬ 
repudiation  of  its  origin.  This  means  that  whoever  opens  the  message  is  assured  of  its 
origin  if  the  sender’s  private  key  is  not  compromised  beeause  at  this  point,  only  the 
sender’s  public  key  opens  the  inner  enerypted  portion. 

2,3  Strand  Spaces  and  Security  Protocols 

A  strand  space  is  a  graph-theoretic  representation  of  a  security  protocol.  A  security 
protocol  is  the  handshaking  that  occurs  between  different  parties,  within  the  context  of 
computer  networks.  The  intent  of  the  handshaking  is  to  ensure  authenticity  of  each  party 
to  the  others,  that  authorized  persons  only  view  a  message’s  content,  and  possibly  to 
generate  and/or  distribute  session  keys.  Session  keys  are  used  temporarily  for  encryption 
during  time-sensitive  conversations.  Their  advantage  is  that  they  expire;  and  if  they  are 
not  compromised,  intercepting  a  message  from  one  session  is  not  mathematically 


6 


equivalent  to  a  message  from  another  session  regardless  of  the  eontents  in  the  message. 
Their  disadvantage  is  that  they  need  to  be  generated  for  eaeh  new  session.  So,  if  there  is 
a  weakness  in  the  protoeol,  a  penetrator  might  be  able  to  aseertain  how  session  keys  are 
being  ereated.  This  very  flaw  is  exploited  in  Needham-Sehroeder  [9]. 

Authentieation  tests  stem  from  an  understanding  of  strand  spaees.  Therefore,  the  first 
topie  covered  is  strand  spaces.  Once  it  is  shown  how  graphs  are  used  to  represent 
protocols,  the  next  logical  step  is  to  show  how  messages  are  formed  and  represented 
along  these  graphs.  This  is  where  the  concept  of  a  test  component  is  introduced.  Then  it 
is  explained  how  outgoing,  incoming  and  unsolicited  tests  are  derived  from  test 
components  and  thus  result  in  the  formulation  of  the  authentication  tests. 

2,3.1  Strand  Spaces  -  Brief  Overview 

To  start,  let’s  assume  for  now  that  a  protocol  only  consists  of  two  parties 
communicating  with  each  other.  Communication  consists  of  a  series  of  discrete  events. 
For  example.  Party  A  sends  some  sort  of  message  to  Party  B.  Party  B  receives  that 
message  and  maybe  sends  another  back,  etc.  This  process  continues  for  whatever  length 
of  time  that  given  protocol  requires.  A  strand  is  the  sequence  of  events  that  occur 
involving  only  one  of  the  parties  (A’s  strand  for  this  protocol;  A  sends  a  message,  A 
receives  a  message,  A  sends  another  message  etc).  A  regular  strand  is  identified  as  a 
legitimate  party’s  strand.  A  strand  space,  shown  as  Z ,  is  the  collection  of  all  strands,  or 
sequences  of  events,  that  can  occur  between  communicating  parties.  It  is  these  ‘strand 
spaces’  which  form  the  basis  of  authentication  tests  [2].  The  authentication  tests  are  a 
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means  of  verifying  whether  a  given  protoeol  ean  sueeessfully  ensure  proper  (intended) 
and  seeure  eommunication  between  the  parties. 

Messages  that  can  be  exchanged  between  communicating  parties  in  a  protocol  are 
called  terms.  Terms  are  elements  of  the  set  of  messages,  called  A,  which  can  be  sent 
between  communicating  parties.  The  set^f  is  freely  generated  from  two  disjoint  sets:  T, 
which  represents  text  (nonces,  names  etc)  and  K,  which  represents  keys.  The  generation 
of  A  from  these  sets  occurs  through  encryption,  concatenation  or  both.  We  show 
transmitted  terms  as  being  preceded  by  a  positive  (+)  sign  and  received  terms  as  being 
preceded  by  a  negative  (-)  sign.  To  further  illustrate  this,  we’ll  use  t  to  represent  a  term 
being  sent  then  received  by  party  A  from  our  example  above.  In  the  above  case,  we 
represent  A  sending  the  term  as:  +  t  and  A  receiving  the  term  as:  - 1.  Also,  a  term  t  is  said 
to  be  a  sub  term  of  f ,  written  as  t  c  t’,  if  one  can  arrive  at  f  by  “repeatedly  concatenating 
[t]  with  arbitrary  terms  and  encrypting  with  arbitrary  keys.”  [8]  Encryption  of  a  term  is 
written  as:  {  t  }Ka  •  If  we  want  to  show  encryption  from  the  use  of  a  particular  party’s 
key,  we  write  this  as:  { t  }Ka  meaning  the  term  is  encrypted  with  A’s  public  key.  A’s 
private  key  is  denoted  Ka'\  To  represent  symmetric  cryptography,  encryption  with  a  key 
shared  by  A  and  B  is  shown  as  {  t  }Kab. 

Strand  spaces  are  based  on  graph  theory  (Figure  2.1).  A  graph  consists  of  edges  and 
vertices.  The  vertices  represent  communication  events,  also  called  nodes.  If  5  is  a  strand, 
then  we  represent  the  1°^  node  along  that  strand  asn  =  <s,  i>.  There  are  two  kinds  of 
edges:  successive  events  (nodes)  within  a  strand  (shown  with  the  double  arrow:  ^)  and 
communication  between  nodes  on  two  separate  strands  (shown  with  the  single  arrow: 
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The  graph  will  be  aeyclie  sinee  events  eannot  go  back  and  precede  events  that  have 
already  occurred.  The  relation  between  nodes  on  the  same  strand  is  represented  as  n 
n’  where  n  =  <s,  i>,  n’  =  <s,j>  and  j  >  i.  The  relationship  between  inter-communicating 
nodes,  meaning  nodes  from  separate  strands,  is  denoted  as  n  ^  n’  where  term(n)  =  +t  and 
term(n’)  =  -t.  Finally,  a  bundle  is  defined  as  a  section  of  the  strand  space  that  is  large 
enough  to  represent  a  full  protocol  exchange.  Figure  2.1  demonstrates  an  example  of  a 
bundle,  although  in  this  case,  the  bundle  consists  of  essentially  the  protocol  itself. 


A  B 

• - >  • 

U  {Na,  Nb)]^a  ^ 

•  < -  • 

-U'  {Nb^  fOj  -U' 

• - >  • 


Figure  2.1  -  Needham- Schroeder  Protocol 
This  brief  introduction  into  the  notation  used  in  strand  space  analysis  suffices  to 
demonstrate  how  a  protocol  is  represented.  Later  in  this  chapter,  this  notation  is  used  to 
show  the  Kerberos  protocol  (Figure  3)  in  detail.  Next,  incoming  and  outgoing  tests  are 
described.  These  tests  are  the  foundation  of  the  authentication  tests. 

2,3,2  Understanding  the  Penetrator 

First,  to  help  understand  why  the  authentication  tests  are  important,  it  is  now 
necessary  to  explain  what  the  tests  help  protocol  designers  guard  against.  The  penetrator 
is  understood  to  be  the  person(s)  who  is  trying  to  perform  any  unwanted  action  during  an 
exchange.  Dolev-Yao  [26]  have  formalized  what  are  understood  to  be  widely  accepted 
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capabilities  of  the  penetrator.  This  formalization  is  termed  the  Dolev-Yao  threat  model. 
Beeause  the  foeus  here  is  not  on  the  mathematieal  soundness  of  eneryption,  it  is 
understood  that  the  penetrator  is  aetually  a  legitimate  party  on  the  network  simply  out  to 
do  no  good,  so  we  term  this  person:  Maliee.  What  ean  Malice  do? 

•  Maliee  ean  obtain  any  message  passing  through  the  network 

•  Maliee  is  a  legitimate  user  and  ean  initiate  eonversations,  and  is  expeeted  at  one 
time,  to  be  a  reeipient  of  an  initiated  eonversation 

•  Maliee  ean  impersonate  any  prineipal  and  thus  send  messages  on  their  behalf  to 
any  other  prineiple  on  the  network 

Dolev-Yao  also  explieitly  state  what  Maliee  ean  not  do: 

•  Maliee  eannot  guess  a  random  number  (i.e.  the  mathematies  of  the  eneryption  is 
assumed  to  be  ideal) 

•  Maliee  eannot  deerypt  properly  enerypted  messages  without  possessing  the  proper 
key;  Maliee  eannot  generate  enerypted  text  on  behalf  of  a  user  without  his  or  her 
proper  key 

•  Maliee  eannot  aseertain  the  eorreet  eorresponding  private  key  of  any  other  user’s 
publie  key 

2,3.3  Authentication  Tests 

Now  that  we  understand  what  we  are  guarding  against,  we  ean  move  onto  the 
authentieation  tests  themselves.  To  understand  the  authentieation  tests  it  is  neeessary  to 
understand  three  simple  tests:  outgoing,  ineoming  and  unsolieited  [4].  It  is  these  three 
tests  that  form  the  foundation  of  the  authentieation  tests. 
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The  key  eomponent  that  these  tests  work  with  is  ealled  a  test  eomponent.  The  formal 
definition  of  a  test  component  is  shown  below  [4]; 

Definition;  t  =  {h}k  is  a  test  component  for  a  in  n  if: 

1 .  act  and  t  is  a  component  of  n; 

2.  The  tern  t  is  not  a  proper  sub  term  of  a  component  of  any  regular  node 
n'  e  Z. 

What  this  states  in  laymen’s  terms  is  that  a  principal  generates  some  a,  and  it  is  a’s 
existence  in  a  component  that  differentiates  between  a  routine  component  and  a  test 
component.  The  transmission  or  reception  of  this  test  component  is  how  we  ascertain 
whether  an  incoming,  outgoing  or  unsolicited  test  occurred. 

An  “outgoing  test  for  a  in  t”  is  when  a  test  component  t  that  contains  a  uniquely 
originating  value  a  is  sent  out  and  a  is  received  back  in  cryptographically  altered  form 
called  t’  (Figure  2.2);  (cryptographically  altered  form  means  that  the  initial  message  is 
decrypted  by  someone  possessing  the  proper  key  and  subsequently  altered)  the 
conclusion  is  that  an  authorized  recipient  received  the  message,  decrypted  it,  extracted 
the  value  a  and  transmitted  it  back.  This  conclusion  relies  on  the  assumption  that  the 
decryption  key,  K'^ ,  is  safe,  or  not  compromised  by  an  attacker,  and  therefore  only  a 
regular  (authorized)  user  could  perform  the  decryption.  The  uniquely  originating  value, 
in  this  case  a,  which  is  a  very  large  randomly  generated  number,  has  very  little  chance  of 
being  guessed  by  another  party.  The  uniquely  originating  term  is  indicated  by  the  *  and 
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we  represent  the  outgoing  test  as:  { . . .a. . . ^  ...a...  where  a  is  the  uniquely  originating 
value. 

A  *a  c  {h}^  =  t 

• - > 

U  act' 

•  < - 

Figure  2.2  -  Outgoing  Test 

Coineidentally,  the  ereation  of  this  unique  number  is  very  eommon.  A  regular  use  of  this 
unique  value  is  as  a  nonce  or  numbers  once;  because  of  their  size  and  randomness,  they 
are  commonly  used  as  session  keys.  The  unaltered  portion  of  the  message  is  this 
uniquely  created  value  because  it  is  possible  that  the  intended  recipient  concatenates 
other  values  to  the  original  message.  With  regard  to  the  graph  representation,  the  part  of 
a  strand  that  receives  a  and  sends  it  back  altered  is  referred  to  as  a  transforming  edge. 

The  part  of  a  strand  that  sends  a  out  and  receives  it  back  altered  is  referred  to  as  a 
transformed  edge.  A  transformed  edge  containing  a  uniquely  originating  term  in  the 
sending  node  is  called  a  test. 

The  incoming  test  works  in  a  similar  fashion.  Given  some  a  transmitted  in  either  plain 
or  encrypted  form,  if  it  is  received  back  unaltered  but  within  a  test  component  properly 
encrypted  by  an  uncompromised  symmetric  key,  we  conclude  that  a  regular  recipient 
performed  the  encryption.  We  write  this  as:  ...a...  ~  {...a...}^^^.  The  unsolicited  test  is 
inherently  weaker  in  nature.  It  states  that  whenever  a  test  component  {  t  is  received, 
assuming  that  symmetric  key  K  is  safe,  then  the  term  could  only  have  originated  on  a 
regular  strand.  Since  the  graphical  representation  of  the  protocol  is  acyclic,  this 
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originating  node  is  located  somewhere  before  the  reception  node.  We  show  this  as: 

{...a... }Kba-  These  three  tests  provide  the  groundwork  for  understanding  how  the 
authentication  tests  work.  Since  the  purpose  of  this  research  is  to  generate  a  tool  that 
automates  security  protocol  verification,  the  following  are  the  formal  definitions  for 
authentication  tests  and  are  drawn  directly  from  [2]: 

Authentication  Test  1:  Let  C  be  a  bundle  with  n'  e  C,  and  let  n  n'  be  an  outgoing 
test  for  a  in  t. 

1 .  There  exist  regular  nodes  m,  in'  ^  C  such  that  t  is  a  component  of  m  and  m  m'  is 
a  transforming  edge  for  a. 

2.  Suppose  in  addition  that  a  occurs  only  in  component  tl  =  {hl}K\  of  m',  that  tl  is 
not  a  proper  subterm  of  any  regular  component,  and  that  K1  ^  ^  P.  Then  there  is  a 
regular  node  with  tl  as  a  component. 

Authentication  Test  2:  Let  C  be  a  bundle  with  n'  e  C,  and  let  n  n'  be  an  incoming 
test  for  a  in  f.  Then  there  exist  regular  nodes  m,  in'  ^  C  such  that  f  is  a  component  of  m' 
and  m  m'  is  a  transforming  edge  for  a. 

Authentication  Test  3:  Let  C  be  a  bundle  with  n  ^  C,  and  let  n  be  an  unsolicited  test  for 
t  =  {h]K.  Then  there  exists  a  positive  regular  node  m  ^  C  such  that  t  is  a  component  of 
m. 
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2,3,4  Tests  Applied  to  Needham-Schroeder 

This  section  shows  how  these  tests  are  visible  in  an  actual  Protocol.  Although  the 
Needham-Schroeder  is  described  later  on  in  great  detail,  it  serves  as  a  good  tool  to  further 
understand  how  the  tests  work. 


A  {Na,A}j^ij  =  f  B 

• - >  • 

''Transformed  Edge”^  U  {Na,  Nb}^^  =  Transforming  Edge” 

*=  f  w/ respect  to  A, =  t  w/ respect  to  B 

•  < -  • 

” Transforming  Edge” {Nb)f^l,  =f  U  <r-” Transformed  Edge” 

• - >  • 

Figure  2.3  -  Annotated  Needham-Schroeder 
Working  from  Figure  2.3,  in  the  first  line,  A  is  sending  his  test  component  out.  The 
message  {A  Na}Kb  is  valid  as  a  test  component  for  reasons  described  in  Section  2.3.3. 
(The  a  in  this  example  is  represented  by  Na)  The  component  is  received  by  B,  who  then 
transforms  the  term  through  decryption,  alteration  and  re-encryption  (only  the  end  result 
is  shown).  With  respect  to  the  SSM,  this  constitutes  the  transforming  edge.  A’s  receipt 
of  this  new  component,  with  respect  to  the  SSM,  is  the  transformed  edge.  The  receipt  of 
this  new  component  in  this  protocol  represents  two  actions:  The  first  is  the  completion  of 
A’s  outgoing  test  and  the  second  is  B’s  transmission  of  his  own  test  component.  Because 
A  has  received  his  test  component  back  altered,  only  through  proper  decryption,  he  can 
infers  a  proper  principal  performed  the  transformation  thus  completing  his  outgoing  test. 
A  then  takes  over  the  role  as  ‘transforming  edge’  with  respect  to  B’s  test  component:  {Na 
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Nb}Ka,  with  the  a,  for  B’s  test  eomponent,  represented  as  Nb.  A  deerypts,  alters  and  re- 
enerypts  B’s  test  component,  then  retransmits  the  new  component  back  to  B.  Once  B 
receives  his  new  component  back,  he  goes  through  the  same  evaluation  proofs  as  A  and 
thus  concludes  a  proper  principal  performed  the  transformation  and  concludes  an 
outgoing  test  has  occurred. 

2,4  Security  Protocol  Examples 

The  strand  space  methodology  enables  the  modeling  of  security  protocols  as  graphs. 
This  section  describes  two  security  protocols  represented  in  the  context  of  strand  spaces. 
The  two  protocols  are:  Needham-Schroeder  [2]  and  Kerberos  [13].  However,  in  an  effort 
to  illustrate  the  use  of  strand  spaces  with  a  particular  protocol,  more  emphasis  is  placed 
on  the  Needham-Schroeder  protocol  as  this  protocol  is  routinely  studied  and  analyzed  in 
the  context  of  strand  spaces  [2,  4  and  5]. 

2,4,1  Types  of  Protocols 

Clark  and  Jacob  identify  basic  categories  that  protocols  fit  into:  Symmetric  or 
Asymmetric  cryptography,  employing  either  trusted  third  parties  or  simply  two 
communicating  principals  [29].  For  the  purpose  of  this  research  only  the  main  three 
protocol  types  are  reviewed.  They  are:  Symmetric  Key  with  Trusted  Third  Party, 
Symmetric  Key  without  Trusted  Third  Party  and  Public  Key.  Symmetric  key  with  trusted 
third  party  is  demonstrated  in  the  Kerberos  protocol.  In  this  protocol,  the  session  keys 
are  generated  by  a  server  and  then  distributed  to  the  requesting  parties.  There  exists  an 
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understanding  that  each  party  has  its  own  secure  symmetric  key  for  use  when 
communicating  with  the  server. 

The  symmetric  key  without  trusted  third  party  is  best  demonstrated  in  challenge- 
response  protocols.  The  way  Needham-Schroeder  is  shown  in  Figure  2. 1 ,  it  could  be 
construed  as  a  challenge  response  protocol  had  the  keys  been  symmetric  vice 
asymmetric.  The  reason  is,  had  the  keys  been  symmetric,  it  would  imply  that  the 
communicating  parties  each  had  prior  knowledge  of  the  key  they  intend  to  use  with  no 
server  generating  it  for  them.  However,  Needham-Schroeder  does  use  asymmetric 
cryptographic  techniques  with  a  trusted  third  party. 

2,4.2  Needham-Schroeder  Protocol 

The  Needham-Schroeder  [24]  public  key  protocol  is  represented  in  Figure  2. 1 .  Later 
in  Chapter  4,  this  protocol  is  shown  with  the  server.  A  description  of  the  protocol 
represented  in  Figure  2. 1  is  as  follows:  The  parameters  A  and  B  represent 
communicating  principals.  The  parameter  N  represents  a  nonce.  The  letter  following  K 
is  indicating  which  node’s  public  key  is  used.  In  the  Needham  Schroeder  protocol,  A 
sends  B  a  nonce  encrypted  with  5’s  public  key.  Along  with  this,  A  sends  B  his  signature; 
in  this  case  a  signature  is  simply  some  agreed  upon  identifier  which  each  party  can  use  to 
know  who  they  are  speaking  to.  Node  B  decrypts  the  message  and  replies  by  sending  A 
the  original  nonce  along  with  a  new  nonce  generated  by  B,  all  encrypted  with  A ’s  public 
key.  Node  A  decrypts  the  message  and  sends  B  his  nonce  back,  encrypted  with  B  ’s  public 
key.  Once  these  events  happen,  it  is  now  understood  that  A  and  B  are  communicating. 
However,  it  is  not  implied  that  this  is  a  secure  sequence  of  events.  In  fact,  it  is  shown  [9, 
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2  and  5]  that  strands  termed  penetrator  strands  are  eapable  of  infiltrating  a  session.  The 
penetrator  strand  represents  an  unauthorized  party  who  has  infiltrated  a  session.  The 
effeet  of  infiltration  varies  significantly  based  upon  the  importance  or  sensitivity  of  the 
session. 

2,4,3  Penetration  of  Needham-Schroeder  Defined 

The  penetration  of  the  Needham-Schroeder  occurs  as  follows  [Figure  2.4]:  Assume 
that  A  wants  to  talk  to  another  party.  In  this  case,  we’ll  call  that  party  P.  A  then  initiates 
a  conversation  with  P,  who  then  encrypts/forwards  ^f’s  information  over  to  party  B.  Party 
B,  thinking  A  initiated  a  conversation  with  him,  will  then  answer  the  challenge  with  a 
reply,  and  also  issue  his  own  challenge.  A  receives  this  message  and  assumes  it  came 
from  P  and  then  replies  to  P  with  the  correct  response.  P  then  encrypts/forwards  this  new 
information  over  to  B  who  sees  it  as  the  correct  information. 


A  {Aa,  P  {Na,A}j^i,  B 

• - >  • - >  • 

JJ  {Na,Nb}Ka 

•  < -  • 

JJ  {Nb}Kp  {Nb}Kt  ^ 

• - >  • - >  • 


Figure  2.4  -  Needham-Schroeder  Penetrated 
Now,  both  parties  are  convinced  they  are  talking  to  their  intended  audience.  However, 
P  now  has  the  nonces  from  each  party  and  is  able  to  eavesdrop  on  a  conversation  between 
A  and  B  or  simply  converse  with  B  while  impersonating  A.  In  [9],  Lowe  proposes  that 
5’s  reply  contain  his  identifier:  (  {  Na,  Nb,  B}Ka  ).  This  will  allow  H  to  see  that 
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somehow  his  information  is  going  to  an  unintended  party  and  deduce  that  P  is  probably 
malicious. 

2,4,4  Kerberos 

Kerberos  is  an  authentication  service  for  open  network  systems  first  proposed  by 
Miller  and  Neuman  [14],  It  involves  three  principals:  user,  client  and  server.  The  basic 
process  works  as  follows.  A  user  desiring  a  service  or  program  contacts  the  client.  The 
client  can  be  anything  from  a  program  to  a  person.  The  client  then  contacts  the  server  on 
behalf  of  the  user.  Kerberos,  using  private  key  encryption,  derives  a  private  key  from  the 
users’  password.  This  key,  along  with  all  other  users’  keys,  is  stored  in  a  Kerberos- 
managed  database.  Any  network  service  requiring  authentication  is  registered  with 
Kerberos.  Also  important  to  note,  Kerberos  maintains  a  list  of  registered  clients,  which 
corresponds  with  a  particular  key.  What  is  evident  here  is  that  Kerberos  acts  as  the 
middleman  between  registered  clients.  Another  role  Kerberos  plays  is  the  generation  of 
session  keys.  Unlike  the  private  keys,  session  keys  are  only  temporary  keys  used  within 
a  limited  timeframe,  as  stated  earlier;  nonces  are  often  used  for  session  keys. 

It  is  now  demonstrated  how  Kerberos  handles  a  request  for  communication  between 
two  parties.  A  first  requests  a  session  key  from  the  authentication  server  that  it  can  then 
use  to  communicate  with  B.  The  session  key  is  a  uniquely  originating  key,  which  is 
ideally  used  for  only  one  session.  First,  A  sends  the  authentication  server,  AS,  its  identity 
and  the  identity  of  whom  it  wants  to  communicate  with.  AS  then  generates  a  symmetric 
session  key,  it  encrypts  the  session  key  and  5’s  identity  with  ^f’s  key.  It  then  encrypts  the 
session  key  and  ^f’s  identity  with  B’s  key  (Figure  2.5).  It  then  sends  both  encrypted 
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messages  to  A.  At  this  point,  A  deerypts  the  session  key  enerypted  with  y4’s  key, 
generates  a  time  stamp,  enerypts  the  time  stamp  with  the  newly  aequired  session  key  and 
sends  both  paekages  off  to  B.  Now,  A  and  B  are  able  to  eommunieate  in  a  seeure  fashion. 

With  respeet  to  the  authentication  tests,  Kerberos  uses  the  incoming  and  unsolicited 
tests.  This  determination  is  made  by  the  fact  that^f  sends  out  plaintext  and  receives  it 
back  properly  encrypted.  This  is  an  example  of  the  incoming  test.  With  respect  to 
incoming  tests,  sending  something  out  plain  and  receiving  it  back  encrypted  does  not 
imply  symmetric  cryptography;  if  that  protocol  uses  asymmetric  cryptography  then  any 
party  can  encrypt  a  plain  message  with  a  public  key  and  one  cannot  conclude  an 
incoming  test  occurred  because  you  cannot  be  sure  who  did  the  encrypting.  However  in 
Kerberos,  A  shares  a  symmetric  key  with  AS  therefore  we  conclude  the  AS  did  the 
encrypting.  B  receives  an  un-requested  message  properly  encrypted  by  this  is  an 
example  of  an  unsolicited  test.  This  protocol  does  not  contain  any  outgoing  tests,  but  it  is 
not  a  requirement  that  all  tests  be  represented  in  a  protocol.  The  presence  of  these  tests 
also  does  not  guarantee  that  Kerberos  is  a  ‘good’  protocol.  The  original  Needham- 
Schroeder  contained  outgoing  tests  with  respect  to  both  parties  but  still  demonstrated  a 
serious  flaw  due  to  the  contents  of  the  messages  themselves. 
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A  {A, 


AS 


B 


• - >  • 

{A,  SK)Kbs,  {FS, 

•  < - • 

U  {A,  SK)Kbs,  { Time-stamp jiSiT 

• - >  • 

Figure  2.5  -  Kerberos  Communieation  Initialization 

2.5  Related  Work  in  the  Automation  of  Security  Protocol  Verification 

Automating  security  protocol  verification  allows  for  quicker  determinations  of  the 
weaknesses  and  strengths  of  a  particular  protocol.  Numerous  researchers  [11]  have 
proposed  applying  formal  proof  techniques  towards  the  analysis  of  security  protocols. 

The  next  sections  briefly  cover  key  work  that  has  been  successful  in  the  automation  of 
security  protocol  verification. 

The  techniques  employed  in  protocol  analysis,  covered  in  this  review,  typically  fall 
into  two  categories.  They  are  model  checking  and  theorem  proving.  In  the  model 
checking  approach,  one  searches  for  desired  states  by  modeling  the  protocol  and 
executing  it  in  every  possible  way.  In  the  theorem  proving  approach,  one  creates  a  search 
tree  and  checks  for  the  existence  of  the  theories  in  that  tree  at  some  state.  The  Multi-Set 
Rewriting  and  Failure  Divergence  Refinement  [22]  checking  typically  fall  into  the  model 
checking  camp.  The  Athena  approach  [11]  falls  into  the  theorem  proving  camp.  The 
approach  in  this  research  falls  into  the  theorem  approach  because  it  automatically 
identifies  where  the  authentication  test  theorems  can  be  applied. 
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2.5.1  Failure  Divergences  Refinement  Checker 

Lowe  [9]  successfully  analyses  the  Needham-Schroeder  protocol  using  the  Failure 
Divergences  Refinement  Checker  (FDR),  which  is  a  model  checker  for  Communicating 
Sequential  Processes  (CSP)  [25].  CSP  is  a  language  that  allows  easy  representation  of 
pattern  interaction.  Using  CSP,  Lowe  tests  whether  a  protocol  achieves  authentication. 

In  the  case  of  an  attacker  being  discovered  [9],  Lowe  is  also  able  to  show  that  the  fixed 
protocol  is  secure. 

2.5.2  Process  Calculus 

In  [1],  Blanchet  uses  an  extension  of  pi-calculus  to  represent  protocols.  Pi-calculus  is 
“a  ‘process  algebra’  in  which  channel  names  can  act  both  as  transmission  medium  and  as 
transmitted  data”  [23].  His  results  show  promise  in  that  automated  protocol  verification 
can  be  done  in  less  than  one  second.  The  user  needs  only  to  correctly  code  whatever 
protocol  they  intend  to  evaluate.  The  tool,  OCaml  3.04  [1],  translates  the  protocol  into 
Horn  clauses  and  then  executes  it  against  rules  based  on  whatever  that  particular  protocol 
defines  as  a  rule.  This  is  obviously  much  faster  than  traditional  methods  of  hand  proving. 
Blanchet  also  permits  an  unbounded  number  of  sessions  within  the  test,  whereas  previous 
work  has  limited  the  number  of  session  due  to  infinite  state  systems.  On  rare  occasions 
the  algorithm  will  not  terminate  and  it  can  even  fail  on  correct  protocols.  However,  it  is 
Blanchet’s  conjecture  that  it  will  terminate  for  a  large  class  of  protocols. 
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2,5.3  Athena 


Athena  is  an  automated  cheeking  algorithm  that  analyzes  security  protocols  [12], 
Athena  implements  a  specialized  logic  for  expressing  security  properties  such  as 
authentication,  secrecy  and  properties  related  to  electronic  commerce  [12],  Athena  works 
by  terminating  and  providing  a  proof  on  well-formed  formulas  or  generating  a  counter 
example  on  well-formed  formulas  that  evaluate  to  false.  Although  there  are  other  formal 
techniques  for  analyzing  security  protocols  [11],  Athena  differs  in  the  sense  that  it  can 
directly  evaluate  the  strand  space  model  without  succumbing  to  the  state  space  explosion 
[1 1,  2.5.1].  State  space  explosion  occurs  whenever  there  is  an  unbounded  number  of 
initiators/responders  and  sessions  thus  creating  an  unreachable  theorem  [18].  Athena 
uses  ‘unreachability  theorems’  to  ‘prune’  the  state  space,  thus  reducing  the  number  of 
states  and  increasing  the  probability  of  terminating  [12].  Another  method  Song  uses  to 
reduce  the  state  space  is  that  of  the  Strand  Space  Model  (SSM)  [28].  By  using  the  causal 
relationships  developed  by  Guttman  in  the  SSM,  Song  is  able  to  further  prune  the  state 
space.  Song  shows  that  although  limited  due  to  its  inability  to  allow  certain  terms  to  be 
encrypted,  Guttman  and  Thayer’s  tests  are  still  effective  in  reducing  the  state  space. 

2.5,4  Security  Modeling  in  Maude 

Object  modeling  software  is  another  effective  way  to  model  protocol  transactions. 

One  example  of  automated  modeling  software  is  Maude  [19].  Maude  was  the  intended 
language  for  this  research,  but  Java  proved  very  effective.  However,  for  future  research 
it  is  highly  recommended  that  using  Maude  to  automate  authentication  tests  be 
performed,  as  this  is  now  explained.  Developed  primarily  at  the  University  of  Illinois 
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and  Stanford  Research  Institute,  Maude’s  purpose  is  stated  as  follows:  “...supporting 
formal  executable  specification,  declarative  programming,  and  a  wide  range  of  formal 
methods  as  means  to  achieve  high-quality  systems  in  areas  much  as:  software 
engineering,  networks,  distributed  computing,  bioinformatics,  and  formal  tool 
development.”  [19]. 

Specifically,  Maude  is  a  “high-performance  reflective  language,  which  supports  both 
equational  and  rewriting  logic  specifications”  [19].  Being  a  reflective  language  means 
that  Maude  can  program  or  manipulate  itself  [20].  Rewriting  logic  allows  for  concurrent 
state  computations.  Although  a  protocol  is  pre-defined  at  run  time,  concurrent  state 
computations  allows  for  rules  or  equational  rewrites  to  occur  simultaneously. 

In  [27],  Denker  and  Meseguer  show  how  protocols  can  be  effectively  modeled  using 
object-oriented  specification  in  Maude.  The  purpose  of  his  work  is  to  show  that  Maude’s 
ability  to  perform  rewritable  logic  and  concurrent  execution  is  helpful  in  uncovering 
security  flaws  in  protocols.  The  paper  uses  the  Needham-Schroeder  public  key  protocol 
as  the  case  study.  Meseguer  implements  a  bounded  depth  first  search  on  multiple 
instances  of  protocol  runs.  The  depth  first  search  shows  efficient  searching  of  possible 
attacks  on  the  multiple  run  is  an  effective  means  of  ascertaining  a  weakness  on  a  given 
protocol.  In  this  case,  the  weakness  discovered  by  Lowe  [9]  is  found  using  a  depth  first 
search.  In  this  example  we  see  Maude  being  used  as  a  model  checker.  However,  Maude 
can  also  be  used  for  theorem  checking.  Because  Maude  is  powerful  enough  to  handle 
either  method  of  use,  it  allows  for  multiple  means  in  which  modeling  the  authentication 
tests  can  be  done. 
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2.5,5  Multi-Set  Rewriting 

In  [22],  Cervesato  et  al.  use  multi-set  rewriting  to  provide  a  means  to  specify  ‘finite 
length’  protocols.  In  his  work,  Cervesato  uses  the  multi-set  rewriting  to  extend  the  strand 
space  formalism.  Through  this  he  is  able  to  model  penetrator  capabilities,  as  defined  by 
Dolev-Yao,  and  then  relate  the  intruder  theory  to  penetrator  strands  as  defined  within  the 
context  of  strand  space  modeling.  This  particular  work  serves  as  a  means  to  further 
understand  the  Dolev-Yao  threat  model. 

2,6  Summary 

This  chapter  outlines  what  a  strand  space  is  and  how  it  is  represented  using  graph 
theory  notation.  It  then  shows  how  this  notation  is  used  to  represent  a  security  protocol. 
The  Needham-Schroeder  and  Kerberos  protocols  were  used  to  illustrate  the  use  of  strand 
spaces.  Next,  three  authentication  tests  were  defined  from  [5].  There  are  three  tests — 
outgoing,  incoming  and  unsolicited — and  each  has  a  theorem  describing  the  guarantees  it 
provides.  Finally,  previous  work  in  automating  aspects  of  security  protocol  analysis  has 
been  discussed. 
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Ill,  Methodology 


3.1  Chapter  Overview 

The  purpose  of  this  chapter  is  to  introduce  the  methods  that  are  employed  in 
automating  the  authentication  tests  developed  by  Guttman  et  al  [2,  5].  This  chapter 
describes  the  Security  Protocol  Analyzer  (SPA)  tool  developed  for  the  purpose  of  this 
research.  The  chapter  also  shows  SPA’s  analysis  of  a  representative  set  of  known 
protocols  and  basic  examples  in  order  to  establish  a  baseline  of  reliability.  In  Chapter  4, 
a  much  more  diverse  set  of  protocols  is  analyzed. 

This  chapter  is  laid  out  in  the  following  manner: 

•  Problem  Review 

•  Overview  of  software  used 

•  Java  based  protocol  analysis 

•  Demonstration  of  tests  in  the  following  environments: 

o  Numerous  one  and  two  pass  tests 
o  Needham-Schroeder 

•  Summary 

3.2  Problem  Review 

The  problem  that  this  research  addresses  is  the  effective  automation  of  security 
protocol  analysis,  and  in  particular,  the  automatic  recognition  of  authentication  tests  as 
defined  by  Guttman  et  al.  Guttman  et  al  have  developed  three  authentication  tests  that 
greatly  simplify  the  tedious  pen-and-paper  proofs  normally  required  to  show  if  a  security 
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protocol  has  certain  correctness  properties.  This  researeh  takes  the  next  step  and 
automates  aspeets  of  their  work.  In  the  previous  ehapter,  these  tests  and  eorreetness 
properties  have  been  defined  and  now  the  foeus  will  shift  to  how  occurrences  of  these 
tests  are  automatically  identified  using  a  tool  developed  in  Java. 

3.3  Software  Overview 

The  Java-based  protocol  analyzer  was  developed  using  the  Java  development 
environment  TogetherSoft®  version  6.0.  This  applieation  was  exeeuted  on  a  Windows® 
2000  operating  system.  The  version  of  Java  that  TogetherSoft®  6.0  employs  is  1.3.1. 

3.4  Java  Based  Protocol  Analysis 

The  protoeol  analyzer  uses  a  traditional  software  development  approaeh  of  objeet- 
oriented  programming.  The  analyzer  uses  dynamically  created  objects  to  represent 
different  eomponent  elasses,  sueh  as  Prineipals,  Messages  and  Text.  The  next  few 
sections  outline  the  algorithm  and  the  speeifie  teehniques  used  in  the  creation  of  the  tool. 

3,4,1  Layout  of  Java  Program 

The  Java-based  program,  ealled  Seeurity  Protoeol  Analyzer  (SPA),  can  be  divided  into 
two  portions.  The  first  portion  is  the  parsing  portion.  The  seeond  portion  is  as  the 
analysis  portion. 
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Table  1  -  Brief  Description  of  SPA  classes 


Class: 

Brief  Description: 

ProtocolAnalyzer 

Main  driver  of  program.  Contains  mam(). 

Encryption 

Checks  encryption  of  messages  against  receiver  and  sender.  Ensures 
proper  parties  are  viewing  messages. 

Protocol 

This  is  the  root  node  of  an  abstract  syntax  tree  representing  a 
protocol.  It  contains  a  list  of  Messages. 

Message 

An  instance  of  message  is  instantiated  as  each  message  is  read  in 
from  the  input  file.  A  message  consists  of  a  sender,  a  receiver  and 
the  term  sent. 

Sequence 

Since  messages  exist  as  concatenations  of  terms,  we  call  this  a 
sequence.  This  class  contains  an  iterator  which  is  traversed  during 
analysis  on  instances  of  Sequence. 

Term 

The  primary  abstract  class  that  enables  Text,  Encryption,  and 

Sequence  to  generically  create  functions  for  recursive  use.  Two  key 
methods  for  analysis,  GetReadableText()  and  GetTextObjO,  are 
established  here. 

Text 

This  class  represents  individual  instances  of  each  text.  If  tagged  with 
a  *  in  the  input  file,  a  flag  condition  is  set  to  show  its  new/fresh 
characteristic. 

Parser 

This  class  checks  the  syntax  of  the  input  file  and  verifies  if  it  is  legal 
or  not.  It  also  builds  an  abstract  syntax  tree  rooted  at  an  instance  of 
the  Protocol  class. 

Principal 

Eor  each  occurrence  of  a  party  within  a  protocol  transaction,  an 
instance  of  principal  is  generated.  Within  it,  the  test  conditions  are 
checked  within  the  addnonce()  method  as  components  get  passed. 

The  main  role  of  the  parsing  portion  is  to  retrieve  a  file  and  import  the  contents  into 
“iterators”  that  the  analyzer  steps  through  and  analyzes.  It  also  builds  the  abstract  syntax 
tree  (AST),  which  is  traversed  during  the  analysis  portion.  The  parsing  method  could 
have  been  done  numerous  ways  therefore  not  much  attention  is  given  to  the  specifics  in 
this  thesis  but  the  authentication  tests  are  strictly  defined  and  hence  that  is  where  our 
focus  lies.  Table  1  lays  out  brief  descriptions  of  key  classes  in  the  SPA.  Sections  3.4.2 
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and  3.4.3  go  into  detailed  specifics  of  the  more  important  operations  and  give  a  more 
thorough  description  of  the  key  classes  as  seen  in  the  SPA  class  diagram,  Figure  3.1. 


ProtocolAnalyzer 


#terms:List 


+Term 
*getRead3bleTexts:voici 
*getComp:vo)d 
+getTexiObj:vo>d 


Message 

#from:String 
#to:String 


+Sequence 

+addTerm:void 

+getComp:void 

+getTextOb);void 

+getReadableTexts:void 

+toString:String 


terins:Listlterator 


#is_nonce:boolean 

#wasfresh:boolean 


♦Text 

+getReadableTexts;void 

+toString:String 

+getComp;void 

+getTextObj;void 


text:  String 
fresh:boolean 


#within;boolean 


+Encryption 

+getComp:void 

+getTextObj:void 

+getReadableTexts:void 

+toString:String 


term:Term 

key:Text 


Principal 


lname:String 

the_fresh_nonce:String 

Iwasfreshiboolean 

Sent_nonces:Vector 

old_nonces:Vector 

S  e  nt_u  n  e  n  c  rypte  d :  Ve  cto  r 

p  e  0  p  I  e_l_s  e  nt_stuff_to ;  Ve  ct  o  r 

m  es  s  a  g  es_l_s  aw:  Ve  cto  r 

sent_message_plain:Vector 

noncesJ_saw:Vector 

compJ_sent;Vector 

hold_text:Text 


♦Principal 

+addnonce:void 


Protocol 


#messages;List 


♦Protocol 

♦addMessage:void 

♦listlteratorListlterator 

♦toString:String 


-Classi 


Figure  3.1  -  Class  Diagram  of  SPA 


3,4,2  Description  of  Parsing  Operation 

The  parsing  of  the  SPA  is  performed  as  follows:  An  input  file  (Figure  3.2)  is  parsed 
line  by  line  into  an  abstract  syntax  tree  with  a  Protocol  object  as  the  root.  A  Protocol 
consists  of  a  list  of  Message  objects.  Each  Message  contains  three  portions:  from,  to  and 
the  message  itself  It  is  this  list  of  messages  that  we  walk  through  during  the  analysis 
portion. 


A->B  :  {A*Nal}Kb 
B->A:  {Nal  *Nbl}Ka 
A->B:  {Nbl}  Kb 
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Figure  3.2  -  Needham-Schroeder  Protocol  Input  File 
Figure  3.3  shows  an  example  of  the  abstract  syntax  tree  created  during  the  initial 
parsing  of  a  message.  As  seen  in  Figure  3.3,  whenever  a  message  is  broken  down,  an 
instance  of  Sequence,  Encryption  or  Text  is  created.  Due  to  the  recursive  structure  of 
message  terms,  within  Encryption  and  Sequence  lie  further  instances  of  Sequence, 
Encryption  or  Text.  The  breakdown  process  continues  recursively  until  individual  Text 
instances  are  all  that  remain.  The  parsing  of  the  input  file  into  AST’s  completes  the 
initial  run  of  the  SPA  with  respect  to  the  input  file.  The  next  operation  performed  is  the 
analysis  portion. 


Eigure  3.3  -  ElML  of  Message  Breakout 


3,4,3  Description  of  Analysis  Operation 

This  section  covers  the  key  classes  that  perform  the  main  analysis.  The 
ProtocolAnalyzer,  Principal  and  Term  classes  are  what  drive  the  analysis  portion  of  the 
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program.  The  ProtocolAnalyzer  class  contains  the  mainQ  function  and  hence  is  the 
driver  for  the  program.  The  program  makes  several  passes  through  the  list  of  messages 
during  the  analysis  portion. 

The  first  pass  through  the  message  list  checks  for  potentially  disqualifying  conditions. 
For  instance,  one  of  the  more  common  conditions  is  occurrence  of  an  encrypted  term 
within  another  encrypted  term,  thus  negating  the  inner  one’s  use  as  a  test  component  in 
accordance  with  criteria  outlined  by  Guttman  [5]  and  described  in  Chapter  2.  The  SPA 
takes  this  encrypted  term  and  stores  it  in  a  vector  with  any  other  disqualified  encrypted 
terms.  If  an  encrypted  term  is  not  disqualified  it  is  stored  in  another  vector  which 
contains  potential  test  components.  Later  on,  these  vectors  are  viewed  to  determine  if  a 
component  received  by  a  Principal  is  disqualified  as  a  test  component  or  not. 

The  second  pass  through  the  message  list  creates  instances  of  the  Principal  class  and 
stores  them  in  a  vector.  Recall  that  during  the  parsing  process,  each  line  of  the  input  file 
generates  a  from,  to  and  message.  The  from  and  to  are  used  to  create  these  instantiations 
of  Principal.  For  example,  using  the  example  in  Figure  3.2,  in  Figure  3.3  A  and  B  are 
created  as  different  instances  of  Principal.  However,  the  parser  first  checks  to  make  sure 
a  previous  existence  of  that  Principal  does  not  exist,  that  way  only  one  instantiation  per 
principal  occurs.  By  having  individual  instantiations  for  each  participant  in  the  protocol, 
this  allows  each  party  to  know  what  terms  and  components  it  has  sent  and  received. 

The  third  pass  is  where  actual  analysis  of  individual  terms  occurs.  Using  Figure  3.2  as 
an  illustration,  whenever  the  first  line  is  analyzed,  individual  terms  A  and  Na  (parsed  into 
an  AST  as  described  earlier),  are  stored  individually  in  a  sent  items  vector  of  A’s 
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instantiation  of  Principal.  B’s  instantiation  of  Principal  will  store  them  in  a  reeeived 
items  veetor.  As  the  SPA  iterates  through  the  list  of  messages,  eaeh  prineipal,  depending 
on  its  role  as  sender  or  reeeiver,  eheeks  its  veetors  of  sent  and  reeeived  items  and  then 
applies  the  rules  of  the  tests  against  that  item.  With  respeet  to  Figure  3.2,  the  SPA 
output  generated  is  shown  in  Figure  3.4.  This  serves  as  a  good  overview  regarding  the 
analysis  operation  but  there  are  two  key  funetions  that  allow  this  to  operate  so  effectively. 

The  first  key  funetion  is  the  GetReadableTextQ  funetion.  The  analyzer  ealls  the 
GetReadableTextO  funetion  initially  in  main{)  to  initiate  the  third  pass,  but  as  deseribed 
shortly,  the  SPA  aetually  traverses  the  tree  through  reeursive  ealls  of  GetReadableTextQ). 
This  reeursion  happens  beeause  the  GetReadableTextQ)  funetion  is  an  abstract  function 
stemming  from  abstraet  elass  Term.  In  order  to  allow  more  effeetive  analysis  without 
duplieation  of  funetionality.  Term  was  developed  as  an  abstract  class  from  which 
Encryption,  Text  and  Sequenee  are  all  extended.  As  the  analyzer  starts  at  the  top  of  the 
AST,  based  on  whatever  instantiation  lies  at  that  partieular  node,  the  SPA  knows  what 
elass’  GetReadableTextQ)  funetion  to  call.  From  within  this  Term,  it  steps  down  to  the 
next  node  and  the  SPA  then  ealls  that  partieular  instanee  of  GetReadableTextQ).  This  is 
espeeially  important  for  enerypted  terms.  If  the  analyzer  is  on  an  enerypted  node,  it  will 
determine  if  the  reeeiver  ean  view  the  message  through  string  eomparisons  on  the  key 
and  Prineipals  identity  (For  example;  Ka  is  viewable  by  A  only).  As  the  analyzer  steps 
further  down  the  tree,  based  on  the  results  of  whether  a  Prineipal  ean  read  the  enerypted 
portion  or  not,  the  analyzer  will  know  whieh  information  to  pass  into  that  Prineipals 
instantiation,  thus,  a  reeeived  item,  if  not  readable,  will  not  be  entered  into  a  reeeiver’s 
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vector  of  received  terms!  (The  actual  addition  of  individual  text  into  a  principals’ 
relevant  vectors  is  done  through  the  addNonceQ  function,  described  shortly.)  Once  the 
end  node  of  the  AST  is  reached,  we  know  from  earlier  that  this  will  be  an  instance  of  an 
individual  Text.  At  this  point,  when  GetReadableTextQ  is  called,  the  values  of  the 
arguments  at  this  point  are  now  ready  to  be  added  directly  into  each  Principal’s  relevant 
vectors. 

Within  the  Text  class’  GetReadableTextQ  function  is  called  the  other  key  function; 
addNonceQ.  AddNonceQ  is  a  method  of  the  Principal  class  that  is  only  called  from 
within  each  individual  instance  of  Text.  In  addNonceQ,  the  following  arguments  get 
passed  in:  the  vectors  of  bad  test  components,  good  test  components,  the  name  of  the 
individual  Text  currently  being  analyzed,  as  determined  by  being  at  the  bottom  of  the 
AST,  and  whether  or  not  the  sender/receiver  can  read  the  individual  Text. 
GetReadableTextQ  of  that  particular  instance  of  Text  will  traverse  the  vector  of  Principals 
then  whenever  sender  and  receiver  get  matched,  that  particular  Principal  has  its 
addNonceQ  function  called.  It  is  within  addNonceQ,  since  we  are  getting  all  the  key 
information  at  this  time  for  this  particular  Text,  that  the  existence  of  the  tests  with 
relation  to  this  particular  Text  are  determined.  The  determination  of  the  existence  of  tests 
follows  strictly  the  criteria  defined  by  Guttman  [5]  and  covered  extensively  in  Chapter  2. 

3.5  Specific  Protocols  analyzed  using  Java 

In  this  section,  the  SPA  is  tested  with  simple  input  to  demonstrate  its  ability  to  find 
examples  of  the  authentication  tests  under  a  variety  of  basic  conditions.  For  example, 
simple  one-pass  and  two-pass  runs  are  performed  using  both  asymmetric  and  symmetric 
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cryptography.  The  chapter  then  culminates  with  the  SPA  running  the  Needham- 
Schroeder  protocol  in  both  a  normal  setting  and  a  setting  with  intentional  flaws.  Once 
these  tests  are  completed,  a  reliable  baseline  is  established  for  use  of  the  SPA  in 
identifying  occurrences  of  outgoing,  incoming  and  unsolicited  tests  in  unfamiliar 
protocols. 

3,5.1  Verifying  Presence  of  Tests 

In  the  first  example,  A  executes  an  incoming  test.  A  sends  out  plain  text  and  receives 
it  back  properly  encrypted  with  a  symmetric  key,  thus  completing  an  incoming  test.  The 
layout  for  all  tests  is  similar  in  nature.  The  SPA  shows  encryption  keys  used  then 
proceeds  to  identify  the  existence  of  any  tests  or  errors. 

File  Contents: 

A  ->  B  :  *Nal  A 
B  ->  A  :  {Nal  B}Kab 

<Parties>  :  <Message>  »  A  ->  B  :  *Nal  A 

Sender  may  be  attempting  to  initiate  an  incoming  test  by  transmitting  Nal  in  tbe  clear. 

<Parties>  :  <Message>  »  B  ->  A  :  {Nal  B}Kab 

Encrypt  term(s)  <  Nal  B  >  with  key  Kab  is  readable  by  both  sender/receiver. 

Tbe  nnencrypted/fresb  nonce  Nal  bas  been  received  back  in  new  component:  {Nal  B}Kab 
Incoming  test  for  A  becanse  fresb  term  Nal  was  sent  ont  earlier  in  <  Nal  > 


In  this  example,  a  simple  two-pass  run  of  an  outgoing  test  is  demonstrated; 

File  Contents: 

A  ->  B  :  {*Nal  A}Kab 
B  ->  A  :  Nal  B 

<Parties>  :  <Message>  »  A  ->  B  :  {*Nal  A}Kab 

Encrypt  term(s)  <  *Nal  A  >  with  key  Kab  is  readable  by  both  sender/receiver. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nal  in  encrypted  form. 
Unsolicited  test  for  B  becanse  of  nonce  Nal  witbin  test  component  <  {Nal  A}Kab  > 

<Parties>  :  <Message>  »  B  ->  A  :  Nal  B 

Tbe  encrypted/fresb  nonce  Nal  bas  been  received  back  in  new  component:  Nal 
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Outgoing  test  for  A  because  fresh  term  Nal  was  sent  out  earlier  in  <  {Nal  A}Kab  > 

In  the  first  pass,  the  SPA  identifies  what  key  is  used  for  eneryption  and  states  which 
parties  can  view  that  part  of  the  message.  Then,  it  states  that  the  sender  may  be  initiating 
an  outgoing  test.  Also,  based  on  the  use  of  symmetric  cryptography,  as  indicated  by  the 
key  format,  it  also  indicates  the  presence  of  an  unsolicited  test  from  B’s  perspective.  B 
transforms  the  message  through  decryption,  once  again,  assuming  the  key  is  safe,  then 
retransmits  it  back  to  A.  Finally,  it  shows  A  completing  an  outgoing  test  because  he  is 
receiving  his  fresh  nonce  back  in  altered  form. 

In  the  below  example,  a  simple  case  of  nested  encryption  is  used  to  demonstrate 
another  example  of  an  outgoing  test.  In  this  case,  A’s  fresh  nonce  is  inside  an  encrypted 
term,  which  is  itself  encrypted.  On  the  first  pass,  the  SPA  shows  both  terms’  encryption 
keys  and  states  how  A  is  attempting  to  initiate  an  outgoing  test.  On  the  second  pass,  the 
SPA  verifies  that  A  has  completed  his  outgoing  test.  Notice  on  this  pass  there  is  no 
unsolicited  test  because  the  communicating  parties  are  using  asymmetric  cryptography, 
as  indicated  by  their  key  format.  Recall  from  Chapter  2,  all  public  keys  are  assumed  to 
be  compromised.  Also,  although  not  shown  by  the  SPA,  the  validity  of  this  test  depends 
on  B’s  private  key  not  being  compromised. 

File  Couteuts: 

A  ->  B  :  A  {{*Nal}Ka}Kb 
B  ->  A  :  {Nal}Ka 

<Parties>  :  <Message>  »  A  ->  B  :  A  {{*Nal}Ka}Kb 

Eucrypted  term(s)  <  {*Nal}Ka  >  with  key  Kb  is  readable  by  recipieut  ouly. 

Eucrypted  term(s)  <  *Nal  >  with  key  Ka  is  readable  by  seuder  ouly. 

Seuder  may  be  attemptiug  to  iuitiate  au  outgoiug  test  by  trausmittiug  Nal  iu  eucrypted  form. 
<Parties>  :  <Message>  »  B  ->  A  :  {Nal}Ka 

Eucrypted  term(s)  <  Nal  >  with  key  Ka  is  readable  by  recipieut  ouly. 
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The  encrypted/fresh  nonce  Nal  has  been  received  hack  in  new  component:  {Nal}Ka 
Ontgoing  test  for  A  hecanse  fresh  term  Nal  was  sent  ont  earlier  in  <  {{Nal}Ka}Kh  > 


The  next  example  is  a  more  eommon  example  of  what  one  would  expeet  during  a 

routine  transaetion  using  symmetrie  eryptography.  In  the  example,  it  shows  the 

unsolieited  test  that  exists  due  to  the  symmetrie  eryptography  used,  as  indieated  by  the 

key  format  used,  but  more  importantly  beeause  of  the  valid  test  eomponent  reeeived  by 

B.  The  only  thing  to  note  here  is  the  phrase  ineoming/outgoing  test.  This  is  not  a  new 

test.  Reeall  from  Chapter  2,  the  outgoing  test  is  sent  out  enerypted  and  reeeived  baek 

altered,  possibly  unenerypted;  the  ineoming  test  is  sent  out  in  either  format  but  reeeived 

baek  enerypted.  Therefore,  this  example  fulfills  the  requirements  of  both  tests  and  eould 

be  ealled  either,  thus  it  is  termed  an  outgoing/ineoming  test! 

File  Contents: 

A  ->  B  :  {*Nal  A}Kah 
B  ->  A  :  {Nal  B}Kah 

<Parties>  :  <Message>  »  A  ->  B  :  {*Nal  A}Kah 

Encrypt  term(s)  <  *Nal  A  >  with  key  Kah  is  readable  by  both  sender/receiver. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nal  in  encrypted  form. 
Unsolicited  test  for  B  hecanse  of  nonce  Nal  within  test  component  <  {Nal  A}Kab  > 

<Parties>  :  <Message>  »  B  ->  A  :  {Nal  B}Kab 

Encrypt  term(s)  <  Nal  B  >  with  key  Kah  is  readable  by  both  sender/receiver. 

The  encrypted/fresh  nonce  Nal  has  been  received  back  in  new  component:  {Nal  B}Kab 
Ontgoing/Incoming  test  for  A  hecanse  fresh  term  Nal  was  sent  ont  earlier  in  <  {Nal  A}Kab  > 


In  this  next  example,  it  appears  as  though  there  should  be  a  simple  ineoming  test. 
However,  this  is  not  the  ease.  A  sends  out  an  unenerypted  fresh  term  and  reeeives  it  baek 
enerypted.  The  SPA  indieates  that  prineipal  A  may  be  attempting  to  initiate  an  ineoming 
test;  however,  beeause  everyone  knows  publie  keys,  A  eannot  be  sure  who  enerypted  his 
plain  text.  The  SPA’s  adherenee  to  the  notion  of  eompromised  publie  keys,  as  diseussed 
in  Chapter  2,  disallows  a  eompleted  incoming  test. 
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File  Contents: 

A  ->  B  :  *Nal  A 
B  ->  A  :  {Nal  B}Ka 

<Parties>  :  <Message>  »  A  ->  B  :  *Nal  A 

Sender  may  be  attempting  to  initiate  an  incoming  test  by  transmitting  Nal  in  tbe  clear. 
<Parties>  :  <Message>  »  B  ->  A  :  {Nal  B}Ka 

Encrypted  term(s)  <  Nal  B  >  with  key  Ka  is  readable  by  recipient  only. 


The  final  example  is  very  similar  to  the  earlier  one  in  whieh  a  term  is  sent  out 

enerypted  and  reeeived  back  altered.  This  represents  an  outgoing  test  for  A  because  test 

component  {*Nal  A}Kb  is  transmitted  to  B.  B  receives  the  test  component,  based  on  the 

input  file  composition,  transforms  the  test  component  into  {Nal  B}Ka  and  transmits  it 

back  to  A.  Since  encryption  is  correct  and  private  keys  are  assumed  safe,  we  see  a  valid 

instance  of  an  outgoing  test. 

File  Contents: 

A  ->  B  :  A  {*Nal  A}Kb 
B  ->  A  :  B  {Nal  B}Ka 

<Parties>  :  <Message>  »  A  ->  B  :  A  {*Nal  A}Kb 

Encrypted  term(s)  <  *Nal  A  >  with  key  Kb  is  readable  by  recipient  only. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nal  in  encrypted  form. 

<Parties>  :  <Message>  »  B  ->  A  :  B  {Nal  B}Ka 

Encrypted  term(s)  <  Nal  B  >  with  key  Ka  is  readable  by  recipient  only. 

Tbe  encrypted/fresb  nonce  Nal  bas  been  received  back  in  new  component:  {Nal  B}Ka 
Ontgoing  test  for  A  becanse  fresb  term  Nal  was  sent  ont  earlier  in  <  {Nal  A}Kb  > 

3,5.2  Analyzing  Needham-Schroeder 

The  above  examples  showed  different  examples  of  the  outgoing,  incoming  and 
unsolicited  tests.  In  this  section  we  expand  upon  this  by  running  an  actual  protocol 
through  the  SPA.  The  result  of  normally  operating  the  Needham-Schroeder  protocol  in 
the  SPA  confirms  the  previously  known  existence  [5]  of  outgoing  tests  in  the  protocol. 
Figure  3.4  shows  the  entire  output  for  the  original  Needham-Schroeder  protocol. 
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A  ->  B  :  {*Nal  A}Kb 
B  ->  A  :  {Nal  *Nbl}Ka 
A  ->  B  :  {Nbl}Kb 

<Parties>  :  <Message>  »  A  ->  B  :  {*Nal  A}Kb 

Encrypted  term(s)  <  *Nal  A  >  with  key  Kb  is  readable  by  recipient  only. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nal  in  encrypted  form. 

<Parties>  :  <Message>  »  B  ->  A  :  {Nal  *Nbl}Ka 

Encrypted  term(s)  <  Nal  *Nbl  >  with  key  Ka  is  readable  by  recipient  only. 

Tbe  encrypted/fresb  nonce  Nal  bas  been  received  back  in  new  component:  {Nal  Nbl}Ka 
Ontgoing  test  for  A  becanse  fresb  term  Nal  was  sent  ont  earlier  in  <  {Nal  A}Kb  > 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nbl  in  encrypted  form. 

<Parties>  :  <Message>  »  A  ->  B  :  {Nbl}Kb 

Encrypted  term(s)  <  Nbl  >  with  key  Kb  is  readable  by  recipient  only. 

Tbe  encrypted/fresb  nonce  Nbl  bas  been  received  back  in  new  component:  {Nbl}Kb 
Ontgoing  test  for  B  becanse  fresb  term  Nbl  was  sent  ont  earlier  in  <  {Nal  Nbl}Ka  > 

Figure  3.4  -  Output  of  running  Needham-Schroeder  in  SPA 
Although  there  are  no  surprises  here,  it  is  important  that  an  aetual  protoeol  was  run. 
From  this,  we  are  now  able  to  move  forward  and  test  protoeols  where  outeomes  may  not 
neeessarily  be  expeeted.  The  final  test  is  to  run  the  Needham-Schroeder  protocol  in 
slightly  altered  form,  then  using  already  known  results  [5],  verify  that  the  analyzer 
generated  the  correct  results. 

In  this  next  test  we  present  an  altered  form  of  Needham-Schroeder.  In  Figure  3.5,  we 
see  several  different  erroneous/mischievous  activities  being  performed.  The  first  is 
principal  C  trying  to  resend  a  previous  message.  The  SPA  generates  no  notice  on  this 
because  it  cannot  assume  this  was  intentional.  It  may  simply  be  acting  as  a  relay.  From 
the  legitimate  test,  it  recognizes  that  A  has  received  his  fresh  nonce  back  and  therefore 
won’t  reregister  this  as  another  outgoing  test.  The  next  activity  is  that  of  B  trying  to 
initiate  a  conversation  using  A’s  old  nonce;  once  again  no  test  is  registered.  These 
duplicate  transactions  do  occur  several  more  times  but  to  no  avail. 
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A  ->  B  :  {A  *Na}Kb 
B  ->  A  :  {Na  *Nb}Ka 
C  ->  A  :  {Na  Nb}Ka 
B  ->  A  :  {B  Na}Ka 
A  ->  B  :  {Na}Kb 
A  ->  B  :  {Nb}Kb 
A  ->  C  :  {Nb}Kc 

<Parties>  :  <Message>  »  A  ->  B  :  {A  *Na}Kb 

Encrypted  term(s)  <  A  *Na  >  with  key  Kb  is  readable  by  recipient  only. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Na  in  encrypted  form. 

<Parties>  :  <Message>  »  B  ->  A  :  {Na  *Nb}Ka 

Encrypted  term(s)  <  Na  *Nb  >  with  key  Ka  is  readable  by  recipient  only. 

Tbe  encrypted/fresb  nonce  Na  bas  been  received  back  in  new  component:  {Na  Nb}Ka 
Ontgoing  test  for  A  becanse  fresb  term  Na  was  sent  ont  earlier  in  <  {A  Na}Kb  > 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nb  in  encrypted  form. 

<Parties>  :  <Message>  »  C  ->  A  :  {Na  Nb}Ka 

Encrypted  term(s)  <  Na  Nb  >  with  key  Ka  is  readable  by  recipient  only. 

<Parties>  :  <Message>  »  B  ->  A  :  {B  Na}Ka 

Encrypted  term(s)  <  B  Na  >  with  key  Ka  is  readable  by  recipient  only. 

<Parties>  :  <Message>  »  A  ->  B  :  {Na}Kb 

Encrypted  term(s)  <  Na  >  with  key  Kb  is  readable  by  recipient  only. 

<Parties>  :  <Message>  »  A  ->  B  :  {Nb}Kb 

Encrypted  term(s)  <  Nb  >  with  key  Kb  is  readable  by  recipient  only. 

Tbe  encrypted/fresb  nonce  Nb  bas  been  received  back  in  new  component:  {Nb}Kb 
Ontgoing  test  for  B  becanse  fresb  term  Nb  was  sent  ont  earlier  in  <  {Na  Nb}Ka  > 

<Parties>  :  <Message>  »  A  ->  C  :  {Nb}Kc 

Encrypted  term(s)  <  Nb  >  with  key  Kc  is  readable  by  recipient  only. 

Figure  3.5  -  Output  of  NS  with  duplicate  transmission  of  nonce 

We  learn  from  this  example  that  the  SPA  is  not  being  fooled  with  repetitive  transactions. 

However,  it  is  catching  and  printing  the  existence  of  the  two  legitimate  outgoing  tests  that 

occur.  As  one  can  see,  there  are  numerous  ways  to  arrange  the  order  of  these  tests  and 

the  components  within,  but  at  this  point  we  can  be  fairly  certain  the  SPA  is  capable  of 

finding  the  tests. 
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3,6  Summary 

In  conclusion,  this  chapter  covered  in  detail  the  basie  operation  of  the  SPA. 
Numerous  test  eases  and  the  Needham-Sehroeder  protoeol  were  run  and  we  use  them  to 
establish  a  baseline  of  reliability.  Finally,  there  was  a  modification  done  to  the  Needham- 
Sehroeder  protoeol  to  show  that  obvious  mistakes  in  a  transaetion,  whether  intentional  or 
not,  eould  be  eaptured.  As  a  result  of  these  tests,  we’ve  shown  that  the  SPA  is  eapable  of 
deteeting  instanees  of  ineoming,  outgoing  and  unsolieited  authentieation  tests  as  well  as 
basie  improper  events  oeeurring  during  the  eourse  of  a  protoeol  run.  We  also  introduee 
something  termed  outgoing/ineoming  test,  whieh  is  the  ease  where  a  reeeived  term  meets 
eriteria  for  both  outgoing  and  ineoming  tests  as  deseribed  in  ehapter  two.  In  the  next 
ehapter,  we  will  expand  upon  this  and  run  the  SPA  against  numerous  protoeols  that 
exhibit  numerous  eharaeteristies. 
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IV.  Analysis  and  Results 


4.1  Chapter  Overview 

This  chapter  demonstrates  the  results  of  running  the  SPA  on  several  regular  protocol 
runs.  These  tests  show  if  any  authentications  tests  oecur  in  the  protocol  and  where. 
Following  the  discussion  of  normal  protocol  runs,  several  more  ‘incorrect’,  or  seemingly 
incorrect,  protocol  runs  are  investigated.  The  purpose  of  ereating  ineorrect  protoeols  is  to 
show  that  the  SPA  is  capable  of  discovering  erroneous  seenarios  that  may  oeeur  in 
protocols.  The  means  by  which  these  particular  scenarios  are  ehosen  is  discussed  later. 

4.2  Results  of  Protocol  Analyses 

This  section  covers  the  overall  results  of  running  known  protocols.  As  discussed 
earlier,  protoeols  are  grouped  into  categories.  Categories  ean  be  broken  up  into  protoeols 
that  use  symmetric  cryptography  verse  asymmetric  cryptography.  Another  category  is 
protocols  which  use  trusted  verse  non-trusted  third  parties.  Although  there  do  exist 
hybrid  protoeols,  the  protoeols  chosen  most  assuredly  fit  into  the  above  categories.  The 
layout  of  the  protocols  is  taken  almost  directly  from  [29]. 

In  Chapter  3,  outgoing,  ineoming  and  unsolieited  tests  output  is  shown  in  great  detail. 
In  this  seetion,  sinee  testing  occurs  on  large  established  protoeols,  previously  unseen 
output  is  displayed.  Although  warnings  and  errors  are  self  explanatory,  there  is  another 
test  condition  that  is  introduced  that  may  not  be  self-evident.  The  test  is  ealled  a  pseudo- 
unsolieited  test.  This  test  does  not  alter  the  definition  of  an  unsolieited  test  in  any  way, 
but  what  it  does  do  is  show  how  one  party  is  receiving  a  challenge  from  another  that  it 
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has  previously  sent  a  message  to.  In  other  words,  beeause  both  parties  understand  the 
protoeol,  A  may  expeet  something  back  from  B,  in  one  case,  the  minimum  reply  might  be 
A’s  fresh  nonce.  However,  simultaneously  if  B  solicits  a  challenge  of  his  own,  A  must 
now  reply  with  the  correct  answer.  The  reason  for  the  slight  name  change  is  based  upon 
the  generic  nature  of  the  analyzer.  This  analyzer  is  able  to  review  any  protocol  without 
knowing  how  the  protocol  works.  But  because  of  this,  it  does  have  to  keep  track  of 
intercommunicating  parties  and  know  who  is  sending  what  to  whom  but  does  not 
necessarily  know  that  a  reply  or  request  is  part  of  the  protocol.  Therefore,  because  a 
party  has  sent  something  to  another  means  receiving  something  back  from  the  party  is  not 
necessarily  ‘unsolicited’. 

4,2,1  Wide  Mouth  Frog  Protocol 

The  wide  mouth  frog  protocol  (Figure  4.1)  involves  the  use  of  symmetric 
cryptography  in  conjunction  with  a  trusted  third  party.  In  this  protocol,  the  initiating 
principal  generates  a  temporary  session  key,  along  with  a  timestamp.  These  are  passed  to 
the  server,  along  with  the  identification  of  the  party  in  which  the  initiating  principal 
wishes  to  communicate.  The  server  then  passes  the  timestamp  and  session  key  onto  the 
intended  recipient. 

The  SPA  recognizes  all  known  tests.  In  the  first  message  it  correctly  identifies  the 
fact  that  A  may  be  attempting  to  initiate  two  different  outgoing  tests.  This  does  not  mean 
they  are  completed;  only  that  A  is  transmitting  a  legitimate  test  component  that  contains 
two  fresh  terms.  S’s  receipt  of  this  valid  test  component  with  two  fresh  terms  inside  and 
the  use  of  proper  symmetric  cryptography  mean  there  exists  two  unsolicited  tests  from 
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S's  perspective.  In  the  second  pass,  5  has  created  his  own  test  component  containing  a 
fresh  nonce  and  thus  may  be  initiating  his  own  outgoing  test.  From  B's  point  of  view,  the 
receipt  of  this  test  component  with  two  fresh  terms,  one  generated  by  S  and  the  other  by 
A,  means  B  has  two  unsolicited  tests.  In  this  example,  the  SPA  accurately  detects  all 
relevant  tests  that  occur  as  shown  in  Figure  4.1. 


A  ->  S  :  A  {*Nal  B  *Kab}Kas 
S  ->  B  :  {*Nsl  A  Kab}Kbs 

<Parties>  :  <Message>  »  A  ->  S  :  A  {*Nal  B  *Kab}Kas 

Encrypt  term(s)  <  *Nal  B  *Kab  >  with  key  Kas  is  readable  by  both  sender/receiver. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nal  in  encrypted  form. 
Unsolicited  test  for  S  becanse  of  nonce  Nal  witbin  test  component  <  {Nal  B  Kab}Kas  > 
Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Kab  in  encrypted  form. 
Unsolicited  test  for  S  becanse  of  nonce  Kab  witbin  test  component  <  {Nal  B  Kab}Kas  > 

<Parties>  :  <Message>  »  S  ->  B  :  {*Nsl  A  Kab}Kbs 

Encrypt  term(s)  <  *Nsl  A  Kab  >  with  key  Kbs  is  readable  by  both  sender/receiver. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nsl  in  encrypted  form. 
Unsolicited  test  for  B  becanse  of  nonce  Nsl  witbin  test  component  <  {Nsl  A  Kab}Kbs  > 
Unsolicited  test  for  B  becanse  of  nonce  Kab  witbin  test  component  <  {Nsl  A  Kab}Kbs  > 

Figure  4.1  -Wide-Mouth  Frog  Protocol 


4.2,2  Yahalom  Protocol 

In  the  Yahalom  protocol,  the  SPA  starts  out  by  showing  how  principal  A  is  initiating 
an  incoming  test  by  sending  out  a  fresh  term.  The  next  message  shows  how  B  is 
initiating  his  own  outgoing  test  and  at  the  same  by  doing  so,  an  unsolicited  test  occurs  for 
the  server,  represented  as  S.  Also,  an  unsolicited  test  occurs  for  nonce  Na  because  it  is 
still  fresh  from  ^’s  view  and  it  exists  within  a  valid  test  component.  The  next  step  then 
shows  how  A  gets  its  nonce,  Na,  back;  thus  completing  the  run  of  its  incoming  test.  At 
the  same  time,  it  shows  an  unsolicited  test  for  A  because  of  a  fresh  term  within  a  valid 
test  component  from  S.  In  this  pass,  the  first  warning  is  generated.  S  has  generated  one 
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key  and  is  transmitting  it  in  two  separate  eomponents.  Beeause  of  this,  if  S  were  to  get 
back  one  of  these  keys,  it  can  not  be  certain  from  whom  and  therefore  they  are 
invalidated  as  a  test  component  with  regard  to  outgoing  tests.  The  final  message  sees  an 
unsolicited  test  for  B  as  well  as  5’s  receipt  of  his  fresh  nonce  back  completing  a  run  of  an 
outgoing/incoming  test. 

The  significance  of  running  Yahalom  in  the  SPA  is  that  the  SPA  is  challenged  with 
multiple  parties,  multiple  test  cases  and  an  encounter  with  its  first  negated  test  component 
and  warning  message.  The  results  of  the  SPA  were  expected  so  therefore  we  conclude 
that  it  has  successfully  completed  analysis  of  this  protocol. 


A  ->  B  :  A  *Na 
B  ->  S  :  B  {A  Na  *Nb}Kbs 
S  ->  A  :  {B  *Kab  Na  Nb}Kas  {A  *Kab}Kbs 
A  ->  B  :  {A  Kab}Kbs  {Nb}Kab 

<Parties>  :  <Message>  »  A  ->  B  :  A  *Na 

Sender  may  be  attempting  to  initiate  an  incoming  test  by  transmitting  Na  in  tbe  clear. 

<Parties>  :  <Message>  »  B  ->  S  :  B  {A  Na  *Nb}Kbs 

Encrypt  term(s)  <  A  Na  *Nb  >  with  key  Kbs  is  readable  by  both  sender/receiver. 

Unsolicited  test  for  S  becanse  of  nonce  Na  witbin  test  component  <  {A  Na  Nb}Kbs  > 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nb  in  encrypted  form. 
Unsolicited  test  for  S  becanse  of  nonce  Nb  witbin  test  component  <  {A  Na  Nb}Kbs  > 

<Parties>  :  <Message>  »  S  ->  A  :  {B  *Kab  Na  Nb}Kas  {A  *Kab}Kbs 

Encrypt  term(s)  <  B  *Kab  Na  Nb  >  with  key  Kas  is  readable  by  both  sender/receiver. 

Unsolicited  test  for  A  becanse  of  nonce  Kab  witbin  test  component  <  {B  Kab  Na  Nb}Kas  > 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Kab  in  encrypted  form. 

Tbe  nnencrypted/fresb  nonce  Na  bas  been  received  back  in  new  component:  {B  Kab  Na  Nb}Kas 
Incoming  test  for  A  becanse  fresb  term  Na  was  sent  ont  earlier  in  <  Na  > 

Unsolicited  test  for  A  becanse  of  nonce  Nb  witbin  test  component  <  {B  Kab  Na  Nb}Kas  > 
Encrypted  term(s)  <  A  *Kab  >  with  key  Kbs  is  readable  by  sender  only. 

Warning:  Sender  is  transmitting  nonce  Kab  in  two  separate  components,  invalidating  its  nse  as  an 
ontgoing  test. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  an  invalid  Kab  in  encrypted 
form. 

<Parties>  :  <Message>  »  A  ->  B  :  {A  Kab}Kbs  {Nb}Kab 

Encrypted  term(s)  <  A  Kab  >  with  key  Kbs  is  readable  by  recipient  only. 

Unsolicited  test  for  B  becanse  of  nonce  Kab  witbin  test  component  <  {A  Kab}Kbs  > 
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Encrypt  term(s)  <  Nb  >  with  key  Kab  is  readable  by  both  sender/receiver. 

The  encrypted/fresh  nonce  Nb  has  been  received  back  in  new  component:  {Nb}Kab 
Ontgoing/Incoming  test  for  B  becanse  fresh  term  Nb  was  sent  ont  earlier  in  <  {A  Na  Nb}Kbs  > 

Figure  4.2  -  Yahalom  Protocol 


4,2,3  Woo-Lam  Protocol 

In  this  section,  the  Woo-Lam  protocol  is  examined.  From  this  point  onward,  rather 
than  explain  line  by  line  each  protocol,  only  key  events  of  the  protocol  and  the  SPA’s 
conclusions  are  discussed.  In  Woo-Lam,  which  is  already  identified  to  have  a  flaw  [5], 
the  SPA  recognizes  two  tests.  The  first  is  the  completed  incoming  test  from  B's  view. 
The  second  is  the  unsolicited  test  from  the  servers’  point  of  view.  However  in  Guttman’s 
work,  [5],  he  concludes  that  their  does  not  exist  a  legitimate  incoming  test.  This 
reasoning  is  based  on  the  notion  that  another  node  could  produce  a  received  component 
of  the  same  form.  Since  the  SPA  performs  tests  based  on  string  comparisons,  in  a  test 
like  this,  type  comparisons  would  be  more  beneficial.  Hence,  a  model  checking  language 
may  prove  more  effective  in  this  type  of  scenario. 


A  ->  B  :  A 
B  ->  A  :  *Nbl 
A  ->  B  :  {Nbl}Kas 
B  ->  S  :  {A  {Nbl}Kas}Kbs 
S  ->  B  :  {Nbl}Kbs 

<Parties>  :  <Message>  »  A  ->  B  :  A 
<Parties>  :  <Message>  »  B  ->  A  :  *Nbl 

Sender  may  be  attempting  to  initiate  an  incoming  test  by  transmitting  Nbl  in  tbe  clear. 

<Parties>  :  <Message>  »  A  ->  B  :  {Nbl}Kas 

Encrypted  term(s)  <  Nbl  >  with  key  Kas  is  readable  by  sender  only. 

<Parties>  :  <Message>  »  B  ->  S  :  {A  {Nbl}Kas}Kbs 

Encrypt  term(s)  <  A  {Nbl}Kas  >  with  key  Kbs  is  readable  by  both  sender/receiver. 
Encrypted  term(s)  <  Nbl  >  with  key  Kas  is  readable  by  recipient  only. 

Unsolicited  test  for  S  becanse  of  nonce  Nbl  witbin  test  component  <  {Nbl}Kas  > 
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<Parties>  :  <Message>  »  S  ->  B  :  {Nbl}Kbs 

Encrypt  term(s)  <  Nbl  >  with  key  Kbs  is  readable  by  both  sender/receiver. 

Tbe  unencrypted/fresb  nonce  Nbl  bas  been  received  back  in  new  component:  {Nbl}Kbs 
Incoming  test  for  B  becanse  fresb  term  Nbl  was  sent  ont  earlier  in  <  Nbl  > 

Figure  4.3  -  Woo-Lam  Protocol 

4,2.4  Neuman-Stubblebine  Protocol 

The  next  protocol  reviewed  is  the  Neuman-Stubblebine  protocol.  In  this  test,  two 
different  scenarios  are  executed.  The  first  (Figure  4.4)  puts  the  *  tag  on  the  nonces  and 
session  keys  generated  by  the  server  and  the  ticket  generated  by  B.  In  other  words, 
anything  created  fresh  and  unique  is  tagged  in  order  to  identify  all  potential  tests.  The 
second  run  (Figure  4.5)  shows  the  analysis  done  without  placing  the  *  on  the  keys  and 
tickets  generated  by  the  different  parties.  The  reason  for  this  is  to  show  that  in  order  to 
detect  the  presence  of  tests,  it  is  important  that  the  analyzers  of  the  protocol  know  what 
they  intend  to  use  as  unique/fresh  terms,  thus  they  have  more  flexibility  when  doing 
analysis. 

In  the  first  test,  numerous  examples  of  unsolicited  tests  are  shown  due  to  the  sheer 
volume  of  freshly  tagged  terms.  At  this  point,  it  is  important  to  note  that  the  SPA  does 
not  disqualify  any  components  but  does  make  note  of  the  fact  that  in  step  3  a  fresh  term 
(a  key)  is  being  transmitted  in  two  components.  Although  this  negates  their  validity  as 
outgoing  tests,  the  SPA  still  makes  the  correct  assessment  and  determines  that  unsolicited 
tests  involving  these  components  do  occur. 

A  ->  B  :  A  *Na 

B  ->  S  :  B  {A  Na  *tb}Kbs  *Nb 
S  ->  A  :  {B  Na  *Kab  tb}Kas  {A  *Kab  tb}Kbs  Nb 
A  ->  B  :  {A  *Kab  tb}Kbs  {Nb}Kab 

<Parties>  :  <Message>  »  A  ->  B  :  A  *Na 
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Sender  may  be  attempting  to  initiate  an  incoming  test  by  transmitting  Na  in  tbe  clear. 

<Parties>  :  <Message>  »  B  ->  S  :  B  {A  Na  *tb}Kbs  *Nb 

Encrypt  term(s)  <  A  Na  *tb  >  with  key  Kbs  is  readable  by  both  sender/receiver. 

Unsolicited  test  for  S  becanse  of  nonce  Na  witbin  test  component  <  {A  Na  tb}Kbs  > 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  tb  in  encrypted  form. 
Unsolicited  test  for  S  becanse  of  nonce  tb  witbin  test  component  <  {A  Na  tb}Kbs  > 

Sender  may  be  attempting  to  initiate  an  incoming  test  by  transmitting  Nb  in  tbe  clear. 

<Parties>  :  <Message>  »  S  ->  A  :  {B  Na  *Kab  tb}Kas  {A  *Kab  tb}Kbs  Nb 
Encrypt  term(s)  <  B  Na  *Kab  tb  >  with  key  Kas  is  readable  by  both  sender/receiver. 

Tbe  nnencrypted/fresb  nonce  Na  bas  been  received  back  in  new  component:  {B  Na  Kab  tb}Kas 
Incoming  test  for  A  becanse  fresb  term  Na  was  sent  ont  earlier  in  <  Na  > 

Unsolicited  test  for  A  becanse  of  nonce  Kab  witbin  test  component  <  {B  Na  Kab  tb}Kas  > 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Kab  in  encrypted  form. 
Unsolicited  test  for  A  becanse  of  nonce  tb  witbin  test  component  <  {B  Na  Kab  tb}Kas  > 

Encrypted  term(s)  <  A  *Kab  tb  >  with  key  Kbs  is  readable  by  sender  only. 

Warning:  Sender  is  transmitting  nonce  Kab  in  two  separate  components,  invalidating  its  nse  as  an 
ontgoing  test. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  an  invalid  Kab  in  encrypted 
form. 

<Parties>  :  <Message>  »  A  ->  B  :  {A  *Kab  tb}Kbs  {Nb}Kab 

Encrypted  term(s)  <  A  *Kab  tb  >  with  key  Kbs  is  readable  by  recipient  only. 

Unsolicited  test  for  B  becanse  of  nonce  Kab  witbin  test  component  <  {A  Kab  tb}Kbs  > 

Tbe  encrypted/fresb  nonce  tb  bas  been  received  back  in  new  component:  {A  Kab  tb}Kbs 
Ontgoing/Incoming  test  for  B  becanse  fresb  term  tb  was  sent  ont  earlier  in  <  {A  Na  tb}Kbs  > 

Encrypt  term(s)  <  Nb  >  with  key  Kab  is  readable  by  both  sender/receiver. 

Tbe  nnencrypted/fresb  nonce  Nb  bas  been  received  back  in  new  component:  {Nb}Kab 
Incoming  test  for  B  becanse  fresb  term  Nb  was  sent  ont  earlier  in  <  Nb  > 

Figure  4.4  -  Neuman-Stubblebine  with  Tags  on  Keys/Tickets 

In  Figure  4.5,  the  Neuman-Stubblebine  is  run  on  the  SPA  without  attaching  the  *  to 

the  keys  or  ticket.  The  only  difference  here  is  that  it  follows  more  closely  with  the  results 

made  by  Guttman  [5].  However,  it  is  not  incorrect  to  show  a  key  or  timestamp,  generated 

similarly  to  a  nonce,  as  fresh  and  denoting  it  with  a  fresh  identifier  as  previously  shown. 

Nor  does  it  negate  the  conclusion  of  the  previous  example. 


A  ->  B  :  A  *NaI 

B  ->  S  :  B  {A  *NaI  Tb}Kbs  *Nbl 
S  ->  A  :  {B  Nal  Kab  Tb}Kas  {A  Kab  Tb}Kbs  Nbl 
A  ->  B  :  {A  Kab  Tb}Kbs  {Nbl}Kab 
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<Parties>  :  <Message>  »  A  ->  B  :  A  *Nal 

Sender  may  be  attempting  to  initiate  an  incoming  test  by  transmitting  Nal  in  tbe  clear. 


<Parties>  :  <Message>  »  B  ->  S  :  B  {A  *Nal  Tb}Kbs  *Nbl 

Encrypt  term(s)  <  A  *Nal  Tb  >  with  key  Kbs  is  readable  by  both  sender/receiver. 

Sender  is  attempting  to  intiate  a  test  with  an  old/invalidated  nonce! 

Unsolicited  test  for  S  becanse  of  nonce  Nal  witbin  test  component  <  {A  Nal  Tb}Kbs  > 

Sender  may  be  attempting  to  initiate  an  incoming  test  by  transmitting  Nbl  in  tbe  clear. 

<Parties>  :  <Message>  »  S  ->  A  :  {B  Nal  Kab  Tb}Kas  {A  Kab  Tb}Kbs  Nbl 
Encrypt  term(s)  <  B  Nal  Kab  Tb  >  with  key  Kas  is  readable  by  both  sender/receiver. 

Tbe  nnencrypted/fresb  nonce  Nal  bas  been  received  back  in  new  component:  {B  Nal  Kab  Tb}Kas 
Incoming  test  for  A  becanse  fresb  term  Nal  was  sent  ont  earlier  in  <  Nal  > 

Encrypted  term(s)  <  A  Kab  Tb  >  with  key  Kbs  is  readable  by  sender  only. 

<Parties>  :  <Message>  »  A  ->  B  :  {A  Kab  Tb}Kbs  {Nbl}Kab 
Encrypted  term(s)  <  A  Kab  Tb  >  with  key  Kbs  is  readable  by  recipient  only. 

Encrypt  term(s)  <  Nbl  >  with  key  Kab  is  readable  by  both  sender/receiver. 

Tbe  nnencrypted/fresb  nonce  Nbl  bas  been  received  back  in  new  component:  {Nbl}Kab 
Incoming  test  for  B  becanse  fresb  term  Nbl  was  sent  ont  earlier  in  <  Nbl  > 

Figure  4.5  -  Neuman-Stubblebine  w/o  Tags  on  Keys/Tickets 


4,2.5  Needham-Schroeder  with  Server 

In  this  test,  the  Needham-Schroeder  protocol  is  executed  on  the  SPA  again.  However, 
unlike  before,  the  server  portion  of  the  protocol  is  included  (Figure  4.6).  This  protocol  is 
drawn  directly  from  [29].  However,  for  clarification,  the  keys  Kas  and  Kbs  are  used  to 
show  when  the  server  is  communicating  with  A  and  B  specifically.  Normal  operation  of 
the  protocol  entails  the  server  using  its  private  key  for  encryption  of  these  messages  and 
assumes  both  parties  have  the  servers’  public  key.  The  use  of  this  key  format  does  not 
alter  the  results  of  the  test. 


A  ->  S  :  A  B 
S  ->  A  :  {Kb  B}KaS 
A  ->  B  :  {A  *Na}Kb 
B  ->  S  :  B  A 
S  ->  B  :  {Ka  A}KbS 
B  ->  A  :  {Na  *Nb}Ka 
A  ->  B  :  {Nb}Kb 
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<Parties>  :  <Message>  »  A  ->  S  :  A  B 


<Parties>  :  <Message>  »  S  ->  A  :  {Kb  B}KaS 

Encrypt  term(s)  <  Kb  B  >  with  key  KaS  is  readable  by  both  sender/receiver. 


<Parties>  :  <Message>  »  A  ->  B  :  {A  *Na}Kb 

Encrypted  term(s)  <  A  *Na  >  with  key  Kb  is  readable  by  recipient  only. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Na  in  encrypted  form. 

<Parties>  :  <Message>  »  B  ->  S  :  B  A 


<Parties>  :  <Message>  »  S  ->  B  :  {Ka  A}KbS 

Encrypt  term(s)  <  Ka  A  >  with  key  KbS  is  readable  by  both  sender/receiver. 

<Parties>  :  <Message>  »  B  ->  A  :  {Na  *Nb}Ka 

Encrypted  term(s)  <  Na  *Nb  >  with  key  Ka  is  readable  by  recipient  only. 

Tbe  encrypted/fresb  nonce  Na  bas  been  received  back  in  new  component:  {Na  Nb}Ka 
Ontgoing  test  for  A  becanse  fresb  term  Na  was  sent  ont  earlier  in  <  {A  Na}Kb  > 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nb  in  encrypted  form. 

<Parties>  :  <Message>  »  A  ->  B  :  {Nb}Kb 

Encrypted  term(s)  <  Nb  >  with  key  Kb  is  readable  by  recipient  only. 

Tbe  encrypted/fresb  nonce  Nb  bas  been  received  back  in  new  component:  {Nb}Kb 
Ontgoing  test  for  B  becanse  fresb  term  Nb  was  sent  ont  earlier  in  <  {Na  Nb}Ka  >  > 

Figure  4.6  -  Needham-Schroeder  Protocol  (w/  Server) 

This  test  results  in  output  similar  to  earlier  tests  with  Needham-Schroeder.  The  only 
real  difference  is  the  interaction  with  the  server  that  occurs  between  each  party. 


4,2.6  Kerberos  Protocol 

The  Kerberos  protocol  results  are  very  similar  to  Neuman-Stubblebine.  In  Chapter  2, 
an  in-depth  description  of  how  this  protocol  works  is  given.  The  layout  used  here,  which 
contains  more  specific  information  in  each  message,  is  taken  directly  from  [29]. 
Regarding  the  analysis,  there  are  no  surprises  in  the  output.  The  only  subjective  action 
was  not  to  tag  all  keys  and  timestamps  as  fresh,  even  though  they  are.  The  reason  is  that, 
based  on  the  Neuman-Stubblebine  output,  nothing  further  would  be  gained  from  this 
except  a  more  lengthy  output. 
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C  ->  A  :  U  G  LI  *N1 

A  ->  C  :  U  {U  C  G  *Kcg  Tst  Tex}Kag  {G  *Kcg  Tst  Tex  Nl}Ku 
C  ->  G  :  S  L2  *N2  {U  C  G  *Kcg  Tst  Tex}Kag  {C  *Tl}Kcg 
G  ->  C  :  U  {U  C  S  *Kcs  Tstl  Texl}Kcg  {S  *Kcs  Tstl  Texl  N2}Kcg 
C  ->  S  :  {U  C  S  Kcs  Tstl  Texl}Kcg  {C  *T2}Kcs 
S  ->  C  :  {T2}Kcs 

<Parties>  :  <Message>  »  C  ->  A  :  U  G  LI  *N1 

Sender  may  be  attempting  to  initiate  an  incoming  test  by  transmitting  N1  in  tbe  clear. 

<Parties>  :  <Message>  »  A  ->  C  :  U  {U  C  G  *Kcg  Tst  Tex}Kag  {G  *Kcg  Tst  Tex  Nl}Kn 
Encrypted  term(s)  <  U  C  G  *Kcg  Tst  Tex  >  with  key  Kag  is  readable  by  sender  only. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Keg  in  encrypted  form. 
Encrypted  term(s)  <  G  *Kcg  Tst  Tex  N1  >  with  key  Kn  is  readable  by  neither  sender  nor  receiver. 
Warning:  Sender  is  transmitting  nonce  Keg  in  two  separate  components,  invalidating  its  nse  as  an 
ontgoing  test. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  an  invalid  Keg  in  encrypted 
form. 

<Parties>  :  <Message>  »  C  ->  G  :  S  L2  *N2  {U  C  G  *Kcg  Tst  Tex}Kag  {C  *Tl}Kcg 
Sender  may  be  attempting  to  initiate  an  incoming  test  by  transmitting  N2  in  tbe  clear. 

Encrypted  term(s)  <  U  C  G  *Kcg  Tst  Tex  >  with  key  Kag  is  readable  by  recipient  only. 

Unsolicited  test  for  G  becanse  of  nonce  Keg  witbin  test  component  <  {U  C  G  Keg  Tst  Tex}Kag  > 
Encrypt  term(s)  <  C  *T1  >  with  key  Keg  is  readable  by  both  sender/receiver. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  T1  in  encrypted  form. 
Unsolicited  test  for  G  becanse  of  nonce  T1  witbin  test  component  <  {C  Tl}Kcg  > 

<Parties>  :  <Message>  »  G  ->  C  :  U  {U  C  S  *Kcs  Tstl  Texl}Kcg  {S  *Kcs  Tstl  Texl  N2}Kcg 
Encrypt  term(s)  <  U  C  S  *Kcs  Tstl  Texl  >  with  key  Keg  is  readable  by  both  sender/receiver. 
Psendo-nnsolicited  test  for  C  becanse  Kcs  is  a  newly  received  fresb  nonce,  bnt  C  bas  sent  items  to  G 
previonsly. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Kcs  in  encrypted  form. 
Encrypt  term(s)  <  S  *Kcs  Tstl  Texl  N2  >  with  key  Keg  is  readable  by  both  sender/receiver. 
Warning:  C  is  seeing  Kcs  again...bnt  it's  tagged  with  *  (fresb)  identifier! 

Warning:  Sender  is  transmitting  nonce  Kcs  in  two  separate  components,  invalidating  its  nse  as  an 
ontgoing  test. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  an  invalid  Kcs  in  encrypted 
form. 

Tbe  nnencrypted/fresb  nonce  N2  bas  been  received  back  in  new  component:  {S  Kcs  Tstl  Texl 
N2}Kcg 

Incoming  test  for  C  becanse  fresb  term  N2  was  sent  ont  earlier  in  <  N2  > 

<Parties>  :  <Message>  »  C  ->  S  :  {U  C  S  Kcs  Tstl  Texl}Kcg  {C  *T2}Kcs 
Encrypted  term(s)  <  U  C  S  Kcs  Tstl  Texl  >  with  key  Keg  is  readable  by  sender  only. 

Encrypt  term(s)  <  C  *T2  >  with  key  Kcs  is  readable  by  both  sender/receiver. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  T2  in  encrypted  form. 
Unsolicited  test  for  S  becanse  of  nonce  T2  witbin  test  component  <  {C  T2}Kcs  > 

<Parties>  :  <Message>  »  S  ->  C  :  {T2}Kcs 

Encrypt  term(s)  <  T2  >  with  key  Kcs  is  readable  by  both  sender/receiver. 

Tbe  encrypted/fresb  nonce  T2  bas  been  received  back  in  new  component:  {T2}Kcs 
Ontgoing/Incoming  test  for  C  becanse  fresb  term  T2  was  sent  ont  earlier  in  <  {C  T2}Kcs  > 
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Figure  4.7  -  Kerberos  Protoeol 


4.2,7  Analyzing  Otway-Rees 

In  this  section,  the  Otway-Rees  protocol  is  analyzed  using  the  SPA.  Figure  4.8  shows 
the  output  generated  from  the  SPA. 


A  ->  B  :  *M  A  B  {*Nal  *M  A  B}Kas 
B  ->  S  :  M  A  B  {Nal  M  A  B}Kas  {*Nbl  M  A  B}Kbs 
S  ->  B  :  M  {Nal  *Kab}Kas  {Nbl  *Kab}Kbs 
B  ->  A  :  M  {Nal  Kab}Kas 

<Parties>  :  <Message>  »  A  ->  B  :  *M  A  B  {*Nal  *M  A  B}Kas 

Sender  may  be  attempting  to  initiate  an  incoming  test  by  transmitting  M  in  tbe  clear. 

Encrypted  term(s)  <  *Nal  *M  A  B  >  with  key  Kas  is  readable  by  sender  only. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nal  in  encrypted  form. 
Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  M  in  encrypted  form. 

Sender  is  sending  tbe  same  nonce  M  ont  both  encrypted  and  plain. 

It  may  only  be  nsed  to  complete  an  incoming  test. 

<Parties>  :  <Message>  »  B  ->  S  :  M  A  B  {Nal  M  A  B}Kas  {*Nbl  M  A  B}Kbs 
Encrypted  term(s)  <  Nal  M  A  B  >  with  key  Kas  is  readable  by  recipient  only. 

Unsolicited  test  for  S  becanse  of  nonce  Nal  witbin  test  component  <  {Nal  M  A  B}Kas  > 

Unsolicited  test  for  S  becanse  of  nonce  M  witbin  test  component  <  {Nal  M  A  B}Kas  > 

Encrypt  term(s)  <  *Nbl  M  A  B  >  with  key  Kbs  is  readable  by  both  sender/receiver. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nbl  in  encrypted  form. 
Unsolicited  test  for  S  becanse  of  nonce  Nbl  witbin  test  component  <  {Nbl  M  A  B}Kbs  > 

<Parties>  :  <Message>  »  S  ->  B  :  M  {Nal  *Kab}Kas  {Nbl  *Kab}Kbs 
Encrypted  term(s)  <  Nal  *Kab  >  with  key  Kas  is  readable  by  sender  only. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Kab  in  encrypted  form. 
Encrypt  term(s)  <  Nbl  *Kab  >  with  key  Kbs  is  readable  by  both  sender/receiver. 

Tbe  encrypted/fresb  nonce  Nbl  bas  been  received  back  in  new  component:  {Nbl  KabjKbs 
Ontgoing/Incoming  test  for  B  becanse  fresb  term  Nbl  was  sent  ont  earlier  in  <  {Nbl  M  A  B}Kbs  > 
Psendo-nnsolicited  test  for  B  becanse  Kab  is  a  newly  received  fresb  nonce,  bnt  B  bas  sent  items  to  S 
previonsly. 

Warning:  Sender  is  transmitting  nonce  Kab  in  two  separate  components,  invalidating  its  nse  as  an 
ontgoing  test. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  an  invalid  Kab  in  encrypted 
form. 

<Parties>  :  <Message>  »  B  ->  A  :  M  {Nal  Kab}Kas 

Encrypted  term(s)  <  Nal  Kab  >  with  key  Kas  is  readable  by  recipient  only. 

Tbe  encrypted/fresb  nonce  Nal  bas  been  received  back  in  new  component:  {Nal  Kab}Kas 
Ontgoing/Incoming  test  for  A  becanse  fresb  term  Nal  was  sent  ont  earlier  in  <  {Nal  M  A  B}Kas  > 
Unsolicited  test  for  A  becanse  of  nonce  Kab  witbin  test  component  <  {Nal  Kab}Kas  > 
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Figure  4.8  -  Output  of  Otway-Rees  protocol  run 
In  the  Otway-Rees  run  there  is  nothing  new  being  seen  by  the  analyzer  that  has  not 
already  been  demonstrated.  The  only  important  thing  to  get  from  this  is  that  the  SPA  is 
capable  of  accurately  finding  authentication  tests  and  examples  of  basic 
mischievous/erroneous  activity. 

4,3  Non-Regular  Protocol  Test  Cases 

This  section  examines  several  test  cases  meant  to  test  the  reliability  of  the  SPA  against 
cases  that,  although  not  representative  of  any  real  protocol,  may  undoubtedly  surface  in  a 
similar  form.  These  test  cases  are  essentially  designed  to  test  the  analyzers  ability  to 
recognize  common  mischievous  activities  as  defined  in  the  Dolev-Yao  threat  model. 

4,3,1  Repeating  Message 

This  section  examines  how  the  SPA  can  verify  a  case  in  which  a  principal  retransmits 

an  identical  message  back  to  the  sender.  In  Figure  4.9,  principal  A  transmits  a  test 

component  containing  a  fresh  nonce.  From  a  receiver’s  point  of  view,  this  constitutes  an 

unsolicited  test.  However,  the  intended  recipient  simply  retransmits  the  message  back  to 

the  sender.  Because  the  component  received  back  is  not  altered,  A  cannot  deduce  that  an 

intended  party  performed  any  action  on  the  component;  therefore,  this  does  not  constitute 

an  outgoing  test. 

A  ->  B  :  {*Na}Kab 
B  ->  A  :  {Na}Kab 

<Parties>  :  <Message>  »  A  ->  B  :  {*Na}Kab 

Encrypt  term(s)  <  *Na  >  with  key  Kab  is  readable  by  both  sender/receiver. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Na  in  encrypted  form. 
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Unsolicited  test  for  B  because  of  nonce  Na  within  test  component  <  {Na}Kab  > 
<Parties>  :  <Message>  »  B  ->  A  :  {Na}Kab 

Encrypt  term(s)  <  Na  >  with  key  Kab  is  readable  by  both  sender/receiver. 

The  encrypted  nonce  Na  has  been  received  back,  but  in  a  duplicated  transmission! 
The  component  {Na}Kab  was  sent  out  identically  by  this  sender. 

Figure  4.9  -  Repeating  Message 


4,3.2  Sub  Term  Relationship  of  Encrypted  Test  Component 

This  section  covers  a  test  that  demonstrates  the  analyzers  ability  to  verify  usage  of  test 

components  as  a  whole  in  an  improper  manner.  Recall  from  Chapter  2  that  the  definition 

of  a  test  component  stipulates  that  a  test  component  cannot  exist  as  a  proper  subterm  of 

any  other  term  on  any  other  regular  node.  In  this  example,  B  attempts  to  use  ^f’s 

encrypted  message  as  his  own  ‘fresh’  term  when  communicating  with  C.  The  analyzer, 

which  looks  ahead,  realizes  this  and  flags  the  original  component  as  invalid!  Because  of 

this,  A  is  no  longer  able  to  complete  is  outgoing  test.  Since  we  are  using  asymmetric 

cryptography,  no  unsolicited  tests  occur  either.  The  only  test  that  might  have  occurred  in 

this  run  would  be  an  outgoing  if  C  gets  his  fresh  nonce  back  at  a  later  time. 

A  ->  B  :  {*Na}Kb 
B  ->  C  :  {{Na}Kb}Kc 
C  ->  B  :  {{Na}Kb  *Nc}Kb 
B  ->  A  :  {Na  Nc}Ka 

<Parties>  :  <Message>  »  A  ->  B  :  {*Na}Kb 

Encrypted  term(s)  <  *Na  >  with  key  Kb  is  readable  by  recipient  only. 

{Na}Kb  is  an  invalid  test  component  because  it's  either  a  proper 
subterm  of  another  component  or  is  a  duplicate  transmission! 

Receiver  is  receiving  an  invalid  test  component  {Na}Kb  otherwise,  it  would  be  an  unsolicited  test 
with  fresh  term  Na 

<Parties>  :  <Message>  »  B  ->  C  :  {{Na}Kb}Kc 

Encrypted  term(s)  <  {Na}Kb  >  with  key  Kc  is  readable  by  recipient  only. 

Encrypted  term(s)  <  Na  >  with  key  Kb  is  readable  by  sender  only. 

<Parties>  :  <Message>  »  C  ->  B  :  {{Na}Kb  *Nc}Kb 

Encrypted  term(s)  <  {Na}Kb  *Nc  >  with  key  Kb  is  readable  by  recipient  only. 
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Encrypted  term(s)  <  Na  >  with  key  Kb  is  readable  by  recipient  only. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nc  in  encrypted  form. 
<Parties>  :  <Message>  »  B  ->  A  :  {Na  Nc}Ka 

Encrypted  term(s)  <  Na  Nc  >  with  key  Ka  is  readable  by  recipient  only. 

Figure  4.10  -  Sub-Term  Re-Eneryption 


4,3.3  Unreadable  Encryption  on  Messages 

The  final  improper  protocol  test  involves  testing  the  SPA’s  ability  to  check  for  proper 

encryption.  In  Figure  4.11,  the  SPA  is  running  the  Needham-Schroeder  protocol  but  on 

line  two  of  the  input  file,  the  encryption  ensures  A  cannot  read  the  message.  Therefore, 

the  SPA  should  not  show  any  example  of  an  outgoing  test.  Correctly  so,  the  SPA  does 

not.  In  fact,  notice  the  SPA’s  ability  to  demonstrate  duplicate  transmission  of  messages. 

A  ->  B  :  {*Na}Kb 
B  ->  A  :  {Na  *Nb}Kb 
A  ->  B  :  {Na  Nb}Kb 

<Parties>  :  <Message>  »  A  ->  B  :  {*Na}Kb 

Encrypted  term(s)  <  *Na  >  with  key  Kb  is  readable  by  recipient  only. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Na  in  encrypted  form. 

<Parties>  :  <Message>  »  B  ->  A  :  {Na  *Nb}Kb 

Encrypted  term(s)  <  Na  *Nb  >  with  key  Kb  is  readable  by  sender  only. 

Sender  may  be  attempting  to  initiate  an  ontgoing  test  by  transmitting  Nb  in  encrypted  form. 

<Parties>  :  <Message>  »  A  ->  B  :  {Na  Nb}Kb 

Encrypted  term(s)  <  Na  Nb  >  with  key  Kb  is  readable  by  recipient  only. 

The  encrypted  nonce  Nb  has  been  received  back,  bnt  in  a  dnplicated  transmission! 

The  component  {Na  Nb}Kb  was  sent  ont  identically  by  this  sender. 

Figure  4.11-  Needham-Schroeder  with  improper  encryption 


4,4  Summary 

This  chapter  described  the  results  of  running  several  normal  protocols  and  several 
incorrect  protocols  on  the  SPA.  The  output  of  each  test  is  described  in  detail  in  order  for 
the  reader  to  have  a  greater  appreciation  of  what  the  tool  is  doing.  It  is  evident  that  the 
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tool  provides  a  reliable  means  of  determining  if  and  where  any  authentication  tests  occur 
in  the  occurrence  of  a  particular  protocol.  The  SPA  also  demonstrates  its  ability  to 
ascertain  improper  behavior,  as  demonstrated  in  the  ‘improper’  protocols.  Although  the 
SPA  is  not  designed  to  show  weaknesses  in  a  protocol,  the  absence  of  authentication  tests 
should  raise  flags  regarding  a  protocol  and  thus  increase  skepticism  regarding  its  security. 
The  next  chapter  gives  final  analysis  of  the  results  of  running  the  SPA  on  communication 
protocols. 
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V.  Conclusions  and  Recommendations 


5.1  Chapter  Overview 

This  chapter  provides  conelusions  as  to  the  suecess  of  the  researeh  and  provides  a 
roadmap  for  future  work  in  the  field  of  protoeol  analysis.  It  provides  insight  into  what 
the  Seeure  Protocol  Analyzer  aceomplishes  and  how  another  modeling  language  may  or 
may  not  provide  better  analysis  of  protoeols  in  the  future. 

5.1  Conclusions  of  Research 

The  SPA  suceessfully  shows  that  protoeol  analysis  with  a  tool  developed  in  Java 
is  highly  valuable  in  the  performanee  of  protoeol  analysis.  In  partieular,  the  SPA  is  able 
to  determine  when  and  where  outgoing,  incoming  and  unsolicited  tests  oecur  within  a 
protoeol  run.  Using  string  eomparisons  vice  type  eomparisons  requires  specific  values  be 
given  and  does  limit  the  application  to  analysis  based  on  completed  static  runs.  However, 
putting  together  numerous  protocols  in  generic  text  files  proves  mueh  easier  than 
individual  protoeol  development  as  noted  in  other  protoeol  analyzers  [27,  11].  It  also 
allows  for  mueh  quicker  analysis  of  the  protoeol  because  it  does  not  have  to  dynamieally 
ereate  a  seareh  tree,  instead  it  only  examines  the  post-run  state  of  the  protocol  as  entered 
in  the  input  text  file.  In  conclusion,  the  SPA  allows  the  taking  of  any  protocol  as  input  in 
a  standard  text  file  and  generates  accurate  output  that  shows  oecurrences  of 
authentieation  tests,  and  it  does  so  very  quickly. 
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5.3  Significance  of  Research 

This  research  is  significant  because  it  creates  a  simple-to-use  tool  that  effectively 
shows  the  presence  of  authentication  tests.  Although  there  are  numerous  other  methods 
for  analyzing  protocols,  this  method  proves  easy  to  use,  accurate  in  its  results  and,  more 
importantly,  it  enables  any  protocol  to  be  entered  in  with  minimal  effort  by  the  user. 
Another  important  result  of  this  work  is  that  output  from  the  SPA  can  be  tailored  to  one’s 
unique  work.  This  opens  the  possibility  that  output  from  the  SPA  could  be  used  as  input 
for  other  theorem  checking  tools  or  protocol  analysis  tools  that  may  look  for  different 
aspects  regarding  a  particular  protocol.  Finally,  this  fast  automation  of  analysis  is 
important  because  the  longer  a  protocol  is  left  in  use  without  in-depth  analysis  being 
performed  on  it,  the  more  the  chance  of  mischievous  persons  finding  a  potential 
weakness  during  its  use  and  exploiting  it. 

5.4  Recommendations  for  Future  Research 

Although  the  tool  is  fairly  complete  in  its  present  form,  added  functionality  will 
certainly  improve  the  effectiveness  of  the  tool.  For  example,  adding  functionality  that 
would  include  provisions  for  penetrator  capabilities.  This  would  entail  adding  in  a  means 
to  examine  static  runs  and  evaluate  what  information  a  penetrator  is  able  to  derive  based 
on  the  Dolev-Yao  threat  model.  From  this  information,  the  tool  might  be  able  to  start 
developing  its  own  messages  in  an  effort  to  show  the  user  that  it  is  possible  to  implant 
false  messages  leading  to  potential  havoc  on  the  principals.  Another  function  worth 
adding  is  that  of  showing  all  the  keys  used  during  the  protocol  exchange.  From  this,  the 
analyzer  can  show  the  keys  actually  used  for  encryption,  whether  they  are  safe  or  not. 
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then  show  the  set  assumed  to  be  safe  as  defined  by  Guttman.  Also,  as  stated  in  [5],  sinee 
the  authentieation  tests  work  even  if  n  and  n'  are  on  different  strands,  add  to  the  analyzer 
the  ability  to  find  the  tests  within  different  strands. 

Another  course  of  action  is  development  in  another  modeling  language  altogether. 
Using  an  analyzer  developed  through  a  model  checker  would  allow  dynamic  creation  of 
search  trees  where  numerous  different  states  can  be  analyzed  showing  not  only  where  and 
when  authentication  tests  occur  but  also  how  to  better  develop  the  protocol  to  ensure  the 
authentication  tests  do  occur  and  that  certain  states  are  never  reached. 

The  other  main  recommendation  for  future  research  is  to  produce  a  similar  analyzer 
using  the  Maude  language  specifically.  As  stated  earlier,  dynamic  evaluation  of 
protocols  allows  users  to  see  first-hand  the  actual  operation  of  a  protocol  run,  versus  the 
after  effect  of  the  run  as  entered  in  static  format.  As  explained  in  Chapter  2,  Maude’s 
rewriting  ability  would  enable  it  to  generate  dynamic  states  very  easily.  With  this 
dynamic  evaluation,  using  a  Dolev-Yao  threat  model,  also  built  into  the  modeling 
language,  the  user  can  ascertain  all  the  possible  states  that  a  protocol  can  be  in  and  all  the 
possible  information  that  can  be  derived.  This  includes  states  that  the  protocol  should  not 
necessarily  be  in.  Limitations  would  have  to  be  placed  on  this  method  to  ensure  that  state 
space  explosion  and  other  problems  do  not  occur  as  described  in  greater  detail  in  Chapter 
2. 

Although  there  are  numerous  other  protocol  analyzers  [11,  12,  24],  none  seem  to 
exhibit  the  all-knowing  power  to  ascertain  whether  protocols  are  susceptible  to  attack. 
However,  built  upon  the  foundation  of  a  solid,  powerful  and  easy  to  use  tool  the  research 
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and  tool  generated  here  gives  analysts  a  clear  roadmap  into  the  future  of  protocol 
analysis. 
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Appendix  A  -  Security  Protocol  Analyzer  Code 


/* 

*  Parser. java 

* 

*  Created  on  December  8,  2003 
*/ 

package  protocols . Parser ; 

import  java.io.*; 
import  j ava . text . * ; 
import  protocols.*; 

/  *  * 

*  This  class  parses  text  from  a  Reader  into  a  Protocol. 

*  @author  rgraham 
*/ 

public  class  Parser 

{ 

/**  Creates  a  new  instance  of  Parser  */ 
public  Parser (Reader  in)  { 
this. in  =  in; 

} 

/**  The  lexical  analyzer,  which  returns  the  next  token  from  the 
Reader.  */ 

private  Token  nextTokenO  throws  ParseException  { 

StringSuffer  sb  =  new  StringSuf f er ( ) ; 
int  type; 

int  ch;  //  It  is  so  annoying  that  read  returns  int! 

if  (nextToken  !=  null) 
return  nextToken; 

/ /  Get  the  next  input  character 
ch  =  getChar ( ) ; 

//  Skip  white  space 

while  (ch  ==  '  '  | |  ch  ==  '\t'  | |  ch  ==  '\r') 

ch  =  getChar  ( ) ; 

//  Read  until  one  complete  token  is  found 
if  (ch  ==  -1) 

type  =  Token. EOF; 
else  if  (ch  ==  '\n') 
type  =  Token. EOL; 
else  if  (ch  ==  ' { ' ) 

type  =  Token . LSRACE; 
else  if  (ch  ==  ' } ' ) 

type  =  Token . RSRACE; 
else  if  (ch  ==  ' : ' ) 

type  =  Token. COLON; 
else  if  (ch  ==  ' * ' ) 

type  =  Token. STAR; 
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else  if  (ch  ==  ' - ' )  { 

getCharO;  //  Skip  '>'  without  checking  it 

type  =  Token .ARROW; 

} 

else  if  (Character . isLetterOrDigit ( (char)  ch) )  { 

do  { 

sb . append ( (char)  ch)  ; 
ch  =  getChar ( ) ; 

}  while  (Character . isLetterOrDigit ( (char)  ch) ) ; 
prev  =  ch; 

type  =  Token. IDENTIFIER; 

} 

else 

throw  new  ParseException ( "Unrecognized  character  ' "  +  ch  + 
" ' " ,  offset)  ; 

nextToken  =  new  Token (type,  sb . toString ( ) ) ; 
return  nextToken; 


/**  Reads  the  next  logical  character  from  the  input,  which  may  be 

the 

*  readahead  character. 

*/ 

private  int  getCharO  { 
int  ch  =  -1; 

if  (prev  !=  0)  { 

ch  =  prev; 
prev  =  0; 

} 

else  { 

try  { 

ch  =  in . read ( ) ; 

}  catch  (Exception  e)  { 

System. err .println (e) ; 

System. err. print in ( "Aborting . " ) ; 

System. exit ( 1 ) ; 

} 

of f set++; 

} 

return  ch; 

} 

public  Protocol  parse ()  throws  ParseException  { 

Protocol  p  =  new  Protocol  (); 

Message  m; 

while  (nextToken (). getType ( )  !=  Token.  EOF)  { 

try  { 

m  =  parseMessage ( ) ; 
p . addMessage (m) ; 

}  catch  (ParseException  e)  { 
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at  offset 


System. err .println (e  +  " 
e . getErrorOf f set ( ) ) ; 

//  Skip  tokens  until  EOL  or  EOF 

while  (nextToken ( ) . getType ( )  !=  Token. EOL 

&&  nextToken (). getType ( )  !=  Token. EOF) 

nextToken  =  null; 


} 

} 

Match (Token . EOF) ; 


return  p; 

} 

/**  Matches  a  specified  token  type  against  the  next  input  token  and 
throws  an 

*  exception  if  it  doesn't  match. 

*/ 

protected  Token  Match (int  t)  throws  ParseException  { 

Token  next  =  nextToken () ; 


if  (next . getType ( )  !=  t) 

throw  new  ParseException ( "Match  Bad  token  "  + 
Token . names [next . getType ( ) ] 


+  ",  expected  "  +  Token . names [t]  , 


offset) ; 


nextToken  =  null;  //  Consume  the  token 
return  next; 


} 


protected  Encryption  parseEncryption ( )  throws  ParseException  { 
Term  m; 

Text  key; 

Match (Token. LBRACE) ; 
m  =  parseTermO; 

Match (Token. RBRACE) ; 
key  =  parseTextO; 

return  new  Encryption (m,  key) ; 

} 

protected  Text  parseTextO  throws  ParseException  { 
boolean  fresh  =  false; 

Token  next  =  nextToken (); 


if  (next . getType ( )  ==  Token. STAR)  { 
fresh  =  true; 

Match (Token . STAR) ; 

} 

Token  id  =  Match (Token . IDENTIFIER) ; 
return  new  Text ( id . getText ( )  ,  fresh); 


protected  Message  parseMessage ( )  throws  ParseException  { 
Text  from,  to; 
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Term  m; 


from  =  parseText ( ) ; 

Match (Token. ARROW)  ; 
to  =  parseText 0  ; 

Match (Token. COLON) ; 
m  =  parseTerm ( ) ; 

Match (Token . EOL) ; 

return  new  Message ( from. getText () ,  to . getText  ( ) ,  m)  ; 

} 

/**  Parses  a  sequence  of  one  or  more  Terms.  If  more  than  one,  it 
returns 

*  a  Sequence  containing  the  Terms  found. 

*/ 

public  Term  parseTerm ()  throws  ParseException  { 

Term  term  =  null,  nextTerm; 

Token  next  =  nextToken ( ) ; 


while  (next . getType ( )  !=  Token. RBRACE  &&  next . getType ( )  != 

Token . EOL 


&&  next . getType ( )  !=  Token. EOF)  { 

if  (next . getType ( )  ==  Token . LBRACE) 
nextTerm  =  parseEncryption ( )  ; 
else  if  (next . getType ( )  ==  Token . IDENTIFIER 
I  I  next . getType ( )  ==  Token. STAR) 
nextTerm  =  parseText ()  ; 

else 


throw  new 


IDENTIFIER  or  STAR", 


ParseException ( "Unexpected  token  " 

+  Token . names [next . getType 0 ] 
+  ",  expected  LBRACE, 

offset) ; 


if  (term  ==  null) 

term  =  nextTerm; 

else  if  (term  instanceof  Sequence) 

( (Sequence)  term) . addTerm (nextTerm) ; 
else  { 

Sequence  temp  =  new  Sequence (); 
temp . addTerm (term) ; 
temp . addTerm (nextTerm) ; 
term  =  temp; 

} 

next  =  nextToken  0; 


if  (term  ==  null) 

throw  new  ParseException ( "Term  expected",  offset); 
return  term; 

} 


protected  Reader  in; 
private  int  prev  =  0; 
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//  Lookahead  character 


/ /  Lookahead  token 


private  Token  nextToken  =  null; 
private  int  offset  =  0; 

} 

/* 

*  Token. java 

* 

*  Created  on  December  8,  2003 
*/ 


package  protocols . Parser ; 

/  *  * 

*  This  class  represents  a  single  Token  parsed  from  an  input  stream. 

* 

*  @author  rgraham 
*/ 

public  class  Token  { 


/**  Creates  a  new  instance  of  Token  */ 
public  Token (int  type.  String  text)  { 
this. type  =  type; 
this. text  =  text; 

} 

public  int  getTypeO  { 
return  type; 

} 


public  String  getTextO  { 
return  text; 

} 


public 

static 

final 

int 

EOF  =  0; 

public 

static 

final 

int 

LBRACE  =  1; 

public 

static 

final 

int 

RBRACE  =  2; 

public 

static 

final 

int 

IDENTIFIER 

public 

static 

final 

int 

ARROW  =  4; 

public 

static 

final 

int 

COLON  =  5; 

public 

static 

final 

int 

EOL  =  6; 

public 

static 

final 

int 

STAR  =  7; 

public  static  String  names []  =  {  "EOF",  "LBRACE",  "RBRACE", 
"IDENTIFIER", 


"ARROW",  "COLON",  "EOL",  "STAR" 


} 


protected  int  type; 
protected  String  text; 


package  protocols; 

/  *  * 

*  Stephen  Mancini  and  Robert  Graham 

*  AFIT/ENG 

*  24  Feb  2004 
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This  is  just  the  abstract  class  that  encryption,  sequence  and  term  are 
extending 
*/ 

import  j ava . util . * ; 
public  abstract  class  Term 
{ 

public  TermO 

{  } 

public  abstract  void  getReadableTexts ( String  Ifrom,  String  Ito, 
Vector  p, 

boolean  readable,  boolean  sent  plain.  String  comp. 

Vector  list  of_components ,  Vector  old_sent.  Vector  bad  test  comp. 
Vector  temp_holdings ,  Vector  text_ob j ,  String  type_enc) ; 

//IF  there  is  a  better  way  to  do  this  I  just  don't  kow  how  right 
now. . .but  at 

//least  I  haven't  reached  13  arguments,  12  means  perfection  ->  13 
means  insanity!  I  I 

public  abstract  void  getComp (Vector  bad  test  comp, Vector 
temp  holdings.  String  Ifrom,  String  Ito,  boolean  outside) ; //Go  through 
tree  and  get  {h}k 

public  abstract  void  getTextObj (Vector  text_ob j ) ; 


} 

package  protocolB; 

/  *  * 

*  Stephen  Mancini  and  Robert  Graham 

*  AFIT/ENG 

*  24  Feb  2004 
RGraham  says: 

*  A  Text  is  a  primitive  (atomic)  Term.  Common  texts  are  principal 
names,  keys 

*  and  nonces.  A  fresh  text  is  one  that  is  generated  dynamically  in 
such  a  way 

*  as  to  be  unique  among  all  other  texts  in  use  (at  least  to  high 
probability, 

*  as  by  a  pseudo-random  process  with  a  sufficient  text  length) . 

* 

What  more  can  I  say?  However,  these  is  where  principal . addnonce  is 
called  for  each  individual  instance  of  a  term. 

It  then  goes  into  that  particular  parties  instance  and  checks  their 
vectors  to  see  if  it  is  completing  a  test 
*/ 

import  j ava . util ; 
public  class  Text  extends  Term 
{ 

/**  Creates  a  new  instance  of  Text  */ 
public  Text (String  text,  boolean  fresh)  { 
this. text  =  text; 
this. fresh  =  fresh; 

if  (fresh)  this . wasf resh  =  true;  //if  it  is  fresh  it  will  have 
once  been  fresh 

//this  wasfresh  should  never  change  because  it  only  says  the 
term  was  fresh  at  one  time 
} 
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public  String  getTextO  { 
return  text; 

} 

public  boolean  isFreshO  { 
return  fresh; 

} 

public  void  getReadableTexts ( String  Ifrom,  String  Ito,  Vector  p, 
boolean  readable,  boolean  sent  plain.  String  comp. 

Vector  list_of  components.  Vector 

old_sent.  Vector  bad_test_comp.  Vector  temp_holdings ,  Vector  text_ob j , 
String  type_enc) 

{ 

int  y  =  0; 

if  (this . isFresh ( ) ) 

{ 

while  (y  <  p.sizeO) 

{ 

Principal  P  =  (Principal)  p . elementAt (y) ; 
if  ( P . Iname . equals I gnoreCase (ifrom) ) 

P . addnonce (text,  "sender",  ifrom,  ito,  readable, 
sent  plain,  true,  comp,  list  of  components,  old  sent,  bad  test  comp, 
temp_holdings ,  text_ob j ,  type_enc) ; 

if  ( P . iname . equal si gnoreCase  (ito) ) 

P . addnonce (text,  "receiver",  ifrom,  ito,  readable, 
sent  plain,  true,  comp,  list  of  components,  old  sent, 
bad_test_comp, temp_holdings ,  text_ob j ,  type_enc) ; 
y++; 

} 

}//End  of  if  it's  fresh 

else//Even  if  it's  not  fresh,  if  it  was  fresh  the  text  obj  vector 
has  each  text  object  in  it,  that  way  I  can  get  more  about  this 
particular  text 

{ 

int  U  =  0; 

String  temp  = 
while  (U  <  p.sizeO) 

{ 

Principal  P  =  (Principal)  p . elementAt (U) ; 

if  ( P . iname . equalsIgnoreCase ( ito) )/ /ito  (below)  used  to  be 
temp,  not  sure  why?should  have  used  comments  earlier! 

P . addnonce (text,  "receiver",  ifrom,  ito,  readable, 
sent  plain,  false,  comp,  list  of  components,  old  sent,  bad  test  comp, 
temp_holdings ,  text_ob j ,  type_enc) ; 

U++ ; 

} 

}//End  of  else  it's  not 

} 
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public  String  toStringO  { 

return  (fresh  ?  :  "")  +  text; 

} 

public  void  getComp (Vector  bad  test  comp.  Vector  temp  holdings. 
String  Ifrom,  String  Ito,  boolean  outside)//.  Vector  text_ob j ) 

{  }//End  of  get  comp 

public  void  getTextObj (Vector  text_ob j ) 

{ 

//I  just  want  my  text  object  which  is  the  {}K  stuff,  in  principal 
I'll  check  if  my 

//individual  term  is  in  the  bad  't' 

boolean  toadd  =  false; //once  I  loop  through  vector  if  text  is  not 
in  there  this  changes  to  true 

int  t  =  0;  //Then  it  gets  added  to  the  list,  ensures 

duplicates  aren't  added 

while  (t  <  text_obj . size ( ) ) 

{ 

Text  temptext  =  (Text)  text  obj . elementAt (t) ; 
if  (temptext . get Text ( ) . equals I gnoreCase (this . get Text ( ) ) ) 

{  toadd  =  true;  } 

t++; 

} / /end  of  while 
if  ( ! toadd) 

{  text_obj . addElement (this) ;  } 

toadd  =  false; //change  it  back  regardless ...  even  though  when  I 
come  back  it  gets  reset  anyways ! ! ! 

}//End  of  getTextObj 

protected  String  text; 
protected  boolean  fresh; 
protected  boolean  is_nonce; 
protected  boolean  wasfresh; 

} 

package  protocolB; 
import  java. util.*; 

/  *  * 

*  Stephen  Mancini  and  Robert  Graham 

*  AFIT/ENG 

*  24  Feb  2004 

*  A  Sequence  is  a  concatenation  of  Terms.  Concatenation  is  assumed  to 
be 

*  associative. 

*  This  class  calls  getreadabletext  based  on  type  of  comp  it  is 
working  with. . . 

*  @author  rgraham 
*/ 

public  class  Sequence  extends  Term 

{ 

/**  Creates  a  new  instance  of  Sequence  */ 
public  Sequence  0  { 
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terms  =  new  ArrayList ( )  ; 

} 

public  void  addTerm(Term  t)  { 
terms . add (t)  ; 

} 

public  Listiterator  getTermsO  { 
return  terms . listiterator ()  ; 

} 

public  void  getComp (Vector  bad  test  comp, Vector  temp_holdings , 
String  Ifrom,  String  Ito,  boolean  outside) 

{ 

System. out . println ( "Enter  getComp  in  sequ"); 

for  (Listiterator  i  =  terms . listiterator  () ;  i . hasNext ( ) ;  ) 

{ 

Term  u  =  (Term)  i.nextO; 

System. out . print ln(u.toString()  )  ; 
if  (u  instanceof  Sequence) 

{//Once  I  am  inside  encryption,  it  has  its  own  way  of  handling 
sequences ...  slightly  different  from  sequence  method 

u . getComp (bad_test_comp,  temp_holdings , if rom,  ito,  outside); 

} 

else  if  (u  instanceof  Encryption) //This  won't  be  internal 
encryption,  that  is  handled  inside  encrpytion 

{//This  is  the  case  where  the  message  comes  in  for  example:  A 
{a}K<-then  it  will  call  encryption  to  check  inside  this 

temp_holdings . addElement (u . toString ());/ /should  add  outside 
encryption  to  temp  holdings 

////////// 

int  max  =  u . toString (). length () ; 
int  Y  =  0; 

String  hold  = 
while  (Y  <  max) 

{ 

if  (! u . toString (). substring (Y, 

Y+1 ) . equals I gnoreCase ( " * " ) ) 

hold  =  hold  +  u . toString (). substring (Y,  Y+1); 

Y++; 

} 

temp  holdings . addElement (hold) ; 

String  holdl  =  hold  +  Ifrom; 

String  hold2  =  hold  +  Ito; 

if  ( ! temp  holdings . contains (holdl ) ) 

if  ( ! temp  holdings . contains (hold2 ) ) 
temp  holdings . addElement (holdl ) ; 

////////7/ 

u . getComp (bad  test  comp, temp_holdings ,  Ifrom,  ito, 
outside) ; //Now  let's  go  inside  the  encryption  and  check  for  term  types 
} 
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else  //What  else  could  it  be?//it  must  be  text  don't  really 
care,  it  does  nothing  anyways 

u . getComp (bad  test  comp, temp  holdings,  Ifrom,  Ito, 

outside) ; 

} 

}//End  of  get  comp  function 

public  void  getTextObj (Vector  text_ob j ) 

{ 

for  (Listiterator  i  =  terms . listiterator () ;  i . hasNext ( ) ;  ) 

{ 

Term  u  =  (Term)  i.nextO; 

u . getTextObj (text  obj);//Call  whatever  instance  of  term  the 
i.next  is 
} 

} 

public  void  getReadableTexts ( String  ifrom.  String  Ito,  Vector  p, 
boolean  readable, 

boolean  sent  plain.  String  comp. 

Vector  list  of  components. 

Vector  old_sent.  Vector  bad_test_comp. 
Vector  temp_holdings ,  Vector  text_ob j ,  String  type_enc) 

{ 

for  (Listiterator  i  =  terms . listiterator () ;  i . hasNext () ;  ) 

{ 


Term  u  =  (Term)  i.nextO; 

if  (u  instanceof  Sequence) //Could  be  more  sequence  of  stuff 

{  u . getReadableTexts ( If rom,  Ito,  p,  readable,  sent_plain, 

comp,  list  of  components,  old  sent,  bad  test  comp,  temp  holdings, 
text_ob j ,  type_enc) ;  } 

else  if  (u  instanceof  Encryption) 

{ 

String  temporary  =  u.toStringO; 

u . getReadableTexts ( if rom,  Ito,  p,  readable,  sent  plain, 
temporary,  list  of  components,  old  sent,  bad  test  comp,  temp  holdings, 
text_ob j ,  type_enc)  ; 

list  of  components . addElement (temporary) ; 

}  //Work  with  component  then  add  it  to  "I've  seen  it 

already"  vector 

else  //It's  either  encryption  or  text  object... 

{//don't  add  text  to  component  list.... 

u . getReadableTexts ( if rom,  Ito,  p,  readable,  sent  plain,  comp, 
list  of  components,  old  sent,  bad  test  comp,  temp  holdings,  text  ob j , 
type_enc) ; 

}//End  of  else  it  isn't  sequence 
}//End  of  for  loop 

}//End  of  GetReadable  Texts ()  function 
public  String  toStringO  { 
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StringBuffer  sb  =  new  StringBuf fer ( ) ; 

for  (Listiterator  i  =  terms . listiterator () ;  i . hasNext ( ) ;  )  { 

sb . append ( ( (Term)  i . next ( ) ) . toString ( ) ) ; 
if  ( i . hasNext ( ) ) 

sb . append ( "  " ) ; 

} 

return  sb . toString  () ; 

} 

protected  List  terms; 

} 

package  protocolB; 

/  *  * 

*  Stephen  Mancini  and  Robert  Graham 

*  AFIT/ENG 

*  23  Feb  2004 

This  is  where  the  main()  function  is.  This  is  the  driver  of  the 
program!  Here  is  where  the  following  occurs: 

individual  instances  of  principal  are  created  from  the  'from'  and  'to' 
of  the  message,  they  are  placed  in  a  vector 

and  passed  around.  Also,  each  message  is  broken  into  components  and 
analyzed  if  it's  a  duplicate  or  subterm  (subterm 

verification  also  is  checked  in  encryption  class) .  Depending  on  check, 
the  comp  is  placed  in  wither  test  comp  vector 

or  bad  comp  vector.  After  this  steps  are  done,  it  then  starts  the 
process  by  analyzing  1  message  at  a  time,  depending 

on  what  the  instance  is,  it  call  getreadabletext .  Since  a  message  may 
contain  sub-parts,  getreadabletext  is  also  called 
recursively  in  other  classes  such  as  encryption  and  text. 

*/ 

//import  Parser.*; 

import  protocolB . Parser .* ; 

import  java.io.*; 

import  java. util.*; 

import  j  ava . text . ParseException; 

public  class  ProtocolAnalyzer  { 

public  static  void  main ( String [ ]  args)  { 
boolean  err  =  false; 

Protocol  protocol  =  null; 

Reader  reader  =  null; 

Vector  num  parties  =  new  Vector (); 

Vector  parties  =  new  Vector (); 

Vector  list  of  components  =  new  Vector ();  //Lists  all 
componentsfu 

Vector  old_sent  =  new  Vector (); 

Vector  bad  test  comp  =  new  Vector ();  //this  one  only  worries 

about 
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//whether  some  t  =  {h}k  is  not  a  proper  subcomponent  of  any 
regular  node 

Vector  temp  holdings  =  new  Vector (); //This  started  out  as  a 
temp  item  but  now  has  evolved  into  a  real  vector  to  be  used 

//it  contains  the  encrypted  terms  that  can  act  as  legitimate 
test  components... 

Vector  text  obj  =  new  Vector ();  //Make  an  instance  of  each  text 
and  pass  it  around 

//The  wonderful  world  of  non-GUI  main  screens 
System. out .println ( )  ; 

System. out . println ( ">>>>>>>>>>>>>>  Protocol-Analyzer  Version 


if  (args. length  ==  0)  { 

System. out . println ( "Nothing  to  parse."); 

System. exit ( 1 )  ; 

} 

System. out . println ( "Parsing  from  file  +  args[0]  + 
try  { 

reader  =  new  FileReader (args  [0] ) ; 

}  catch  (Exception  e)  { 

System. out .println  (e) ; 

System. exit  ( 1 ) ; 

} 

Parser  p  =  new  Parser ( reader ) ; 
try  { 

protocol  =  p. parse  0; 

}  catch  ( ParseException  e)  { 

System. out .println (e  +  "  at  offset  "  +  e . getErrorOf f set ( ) ) ; 
err  =  true; 

}  catch  (Exception  e)  { 

System. out .println (e) ; 
err  =  true; 

} 

if  ( ! err) 

System. out . println ( "File  Contents:\n"  +  protocol); 

for  (Listiterator  i  =  protocol .  listiterator  ()  ;  i.hasNextO;  ) 

{ 

Message  t  =  (Message)  i.nextO; 

//Lets  count  the  number  of  unique  parties  in  the  given 

protocol 

if  ( ! num  parties . contains (t . from) ) 
num  parties . addElement (t . from) ; 

if  (! num_parties . contains (t . to)  ) 
num  parties . addElement (t . to) ; 

}//End  of  for  loop  which  creates  principal  instances... 

//Start  creating  instances  of  party  for  each  player  in  the 

protocol 
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string  temp  = 
int  j  =0; 

while  (j<num  parties . size  () ) 

{ 

temp  =  num  parties . elementAt ( j ). toString () ; 

Principal  PPP  =  new  Principal (temp) ; 
parties . addElement (PPP)  ; 
temp  = 

j++; 

} 

///////////This  section  will  run  through  the  whole  protocol  and  get  all 
components  for 

///////////later  testing  on  subterm  relationships... 

///////////Will  also  do  the  text_obj  stuff  in  here 

for  (Listiterator  i  =  protocol . listiterator () ;  i . hasNext ( ) ;  ) 

{ 

Message  t  =  (Message)  i.nextO; 

Term  g  =  (Term)  t . getTerm ( ) ; 

if  (g  instanceof  Sequence) 

{ 

Sequence  S  =  (Sequence)  g; 

for  (Listiterator  k  =  S . getTerms ( ) ;  k . hasNext (); ) 

{ 

Term  1  =  (Term)  k.nextO; 

1 . getComp (bad  test  comp,  temp  holdings,  t.from,  t.to, 

true)  ; 

l.getTextObj (text_obj) ; 

}//End  of  for  loop  within  sequence 
}//End  of  if  statement 
else  if  (g  instanceof  Encryption) 

{ 

temp  holdings . addElement (g) ; 

//This  part  makes  copy  and  puts  it  in  without  *  so  I  can 
check  for  duplicate  later 

int  max  =  g . toString (). length () ; 
int  Y  =  0; 

String  hold  = 
while  (Y  <  max) 

{ 

if  (! g . toString (). substring (Y, 

Y+1) . equalsIgnoreCase ("*") ) 

hold  =  hold  +  g . toString (). substring (Y,  Y+1); 

Y++; 

} 

temp  holdings . addElement (hold) ; 

String  holdl  =  hold  +  t.from; 

String  hold2  =  hold  +  t.to; 

if  ( ! temp  holdings . contains (holdl ) ) 

if  ( ! temp  holdings . contains (hold2 ) ) 
temp  holdings . addElement (holdl ) ; 
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true)  ; 


g . getComp (bad_test_comp,  temp_holdings ,  t.from,  t.to, 
g.getTextObj (text_obj) ; 

} 

else  if  (g  instanceof  Text) 

{ 

g . getComp (bad_test_comp,  temp_holdings ,  t.from,  t.to, 

true)  ; 

g.getTextObj (text_obj) ; 

} 

}//End  of  for  loop  through  evaluation  of  entire  protocol  for 
potential  test  components 

//What  this  part  does  is  take  the  terms  in  my  array  of  suspect 
comp's  and  remove  *,  so  that 

//someone  doesn't  retransmit  exact  same  message  back 
//for  example:  {*N}Kmn  then  resend  as  {N}Kmn  is  not  valid 
outoging  test! 

/*  int  h  =  0; 

int  max  =  bad  test  comp . size () ; 

String  holder  = 

String  temporary2  = 
while  (h  <  max) 

{ 

holder  =  bad  test  comp . elementAt (h) . toString ( ) ; 
int  y  =  0; 

while  (y  <holder . length () ) 

{ 

if  ( I  holder . substring (y, y+1 )  . equals I gnoreCase ( " * " ) ) 

temporary2  =  temporary2  +  holder . substring (y, y+1 ) ; 
y++; 

}//End  of  innner  while 

bad  test  comp . addElement (temporary2 ) ; 
temporary2  = 
h++ ; 

}//End  of  outer  while*/ 

//Take  out  the  *  in  the  temp  holding  vector 
/*  int  h  =  0; 

int  max  =  temp  holdings . size () ; 

String  holder  = 

String  temporary2  = 
while  (h  <  max) 

{ 

holder  =  temp  holdings . elementAt (h) . toString () ; 
int  y  =  0; 

while  (y  <holder . length () ) 

{ 

if  ( I  holder . substring (y, y+1 )  . equal si gnoreCase  (  " * " ) ) 

temporary2  =  temporary2  +  holder . substring (y, y+1 ) ; 
y++; 

}//End  of  innner  while 

temp  holdings . addElement (temporary2 ) ; 
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temporary2  = 
h++ } 

} / /End  of  outer  while*/ 

///MORE  DEBUG  CODE  JUST  DUMPS  VECTORS  OF  COMP  DEBUG  CODE/// 

/*  int  K  =  0; 

while  (K  <  bad_test  comp . size () ) 

{//This  is  for  testing  purposes 
System. out . println ( "Bad  test  comp:  "  + 
bad_test_comp . elementAt (K) .toStringO ) ; 

K++; 

} 

K  =  0; 

while  (K  <  temp  holdings . size () ) 

{//This  is  for  testing  purposes 
System. out . println ( "Temp  holdings:  "  + 
temp  holdings . elementAt (K) . toString ( ) ) ; 

~  K++; 

}*/ 

//DEBUG  CODE  DEBUG  CODE  //Test  the  text_obj  vector  //DEBUG  CODE 
/*  int  w  =  0; 

while  (w  <  text  obj.sizeO) 

{ 

Text  temptext  =  (Text)  text  ob j . elementAt (w) ; 

System. out . println ( "The  PA  output  in  vector  is:  "  + 
temptext . toString ( ) ) ; 

W++  f 

} / /end  of  while*/ 

/ II II II II II /End  of  my  latest  monster  code  which  follows  well  that  of 
the  pasta  class!  Still, 

II II II II II II  "lE  is  quite  ingenious ....  or  I  must  be  losing  it,  or  I  am  a 

genious . . . only  voice  number  3 

II II II II II II In  my  head  knows  the  truth  :-) 

for  (Listiterator  i  =  protocol . listiterator () ;  i . hasNext ( ) ;  ) 

{ 

Message  t  =  (Message)  i.nextO; 

System. out .println ( ) ; 

System. out . println ( "<Parties>  :  <Message>  >>  "  + 
t . toString ( ) ) ; 

Term  g  =  (Term)  t . getTerm ( ) ; 

String  type  enc  =  "ASYM"; 

if  (g  instanceof  Sequence) 

{ 

Sequence  S  =  (Sequence)  g; 

for  (Listiterator  k  =  S . getTerms ( ) ;  k . hasNext  (); ) 

{ 

Term  1  =  (Term)  k.nextO; 

1 . getReadableTexts (t . from,  t.to,  parties,  false,  true, 

1 . toString 0 ,  list_of_components ,  old_sent,  bad_test_comp, 
temp_holdings ,  text_ob j ,  type_enc) ; 
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} 


} 

else  if  (g  instanceof  Encryption) 

{ 

g . getReadableTexts (t . f rom,  t.to,  parties,  false,  true, 
g . toString ( ) ,  list_of_components ,  old_sent,  bad_test_comp, 
temp_holdings ,  text_ob j ,  type_enc) ; 

list  of  components . addElement (g . toString ());/ /Work  with 
component  then  add  it  to  "I've  seen  it  already"  vector 
} 

else 

{ 

g . getReadableTexts (t . from,  t.to,  parties,  false,  true, 
g . toString 0 ,  list_of_components ,  old_sent,  bad_test_comp, 
temp_holdings ,  text_ob j ,  type_enc) ; 

} //Don't  add  plain  text  to  comp  vector 

} 

} / /End  of  main 
}//End  of  class 
package  protocolB; 

/  *  * 

*  Stephen  Mancini  and  Robert  Graham 

*  AFIT/ENG 

*  23  Feb  2004 

This  is  a  key  class.  Here  is  where  an  addnonce,  that  is  called  from 
text  class,  ends  up.  This  has 

numerous  flags  and  variables  passed  in.  This  class  does  the  test  for 
tests.  Whenever  the  string  value 

is  set  to  sender,  values  sent  in  apply  to  that  particular  instance  of 
sender,  created  in  protocolanalyzer  class. 

Likewise  for  receiver.  Not  much  else  to  say  on  this  class  except  that 
tests  work  basically  like  this:  Whenever  I 

am  in  sender  mode,  whatever  nonce  is  passed  in  is  placed  in  a  vector 
(sent  nonces  if  encr/sent  unencrypted  is  sent  unencr) 

As  long  as  the  comp  isn't  disqualified,  that  is.  These  flags  are 
checked  mostly  in  all  the  if's  of  the  receiver. 

Then  whenever  I  am  receiver,  I  check  through  my  sent  nonce  and 

sent  unencerypted  vectors  and  see  if  the  nonce  passed 

in  is  there,  if  so  it  completes  whatever  test  is  applicable. 

*/ 

import  j ava . util . * ; 
public  class  Principal 
{ 

String  Iname  = 

String  the  fresh  nonce  = 
boolean  Iwasfresh  =  false; 

Vector  Sent_nonces  =  new  Vector (); 

Vector  old_nonces  =  new  Vector (); 

Vector  Sent_unencrypted  =  new  Vector (); 

Vector  people_I_sent_stuf f_to  =  new  Vector (); 

Vector  messages  I  saw  =  new  Vector (); 

Vector  sent  message  plain  =  new  Vector (); 
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Vector  nonces  I  saw  =  new  Vector (); 

Vector  comp_I_sent  =  new  Vector (); 

Text  hold  text; 

public  Principal ( String  tname) 

{  Iname  =  tname;  } 

public  void  addnonce ( String  nonce.  String  person.  String  from. 
String  Ito,  boolean  readable,  boolean  sent  plain,  boolean  is  fresh. 
String  comp.  Vector  list  of  components.  Vector  old  sent. 
Vector  bad  test  comp.  Vector  temp  holdings.  Vector  text  ob j ,  String 
type_enc) 

{//readable  is  set  in  encryption  class ... isfresh  is  set  in  text 
class .... 

//sent  plain  is  set  to  ture  initially,  then  changed  in 
encryption  class 

//from  and  ito  only  have  values  depending  on  whose  key  it  is 

String  temp  comp  =  comp  +  ito; //This  is  how  I  set  the  string 
to  look  for  duplicate  retransmission  of  messages 

//in  other  words,  if  I  sent  out  lets  say  A  sent  out  a  comp 
{a}Ka  and  it  is  concat  with  A  so  it  is  {a}Ka  +  A  =  {a}KaA  then  later  I 
am  receiving  it  back 

//to  check  for  duplication  I  concatenate  the  ito, 

//let's  say  it  is  A  getting  it  back,  so  then  it  becomes 
{a}KaA,  well  they  match  so  obviously  someone  sent  A's  original  comp 
back  <-that's  bad! 

//This  part  goes  and  get's  the  object  of  the  nonce  and  then 
we  can  ascertain  it's  current  status  (fresh  or  was  fresh) 

//that  way  if  I  want  to  add  more  info  about  a  text  object,  I 
can  and  it's  real  easy  to  get  now! 

//Maybe  I  can  add  a  value  that  says  who  the  originator  was, 
then  I  can  populate  that  value  here  locally 

//and  then  based  on  Ifrom  and  ito  I  can  decide  more 
accurately  about  the  tests?  FUTURE  WORK! 
int  U  =  0; 

while  (U  <  text_obj . size  ( ) ) 

{ 

Text  temptext  =  (Text)  text  ob j . elementAt (U) ; 
if  (nonce . equals I gnoreCase (temptext . get Text ( ) ) ) 

{//Could  populate  any  variable  I  want  here  that  the 
particular  text  object  might  hold.  (Future  work?) 

//or  I  could  just  stop  the  loop  and  work  with  temptext 
hold_text  =  temptext;  //I  may  need  to  use  this  object 
later. .in  fact  I  will! ! ! 

Iwasfresh  =  temptext . wasfresh; 

}//End  of  if  and  end  of  populating  variables! 

U++ ; 

}//End  of  while  through  text  objects 

//Let's  go  ahead  and  take  out  the  *  in  the  comp  because  a 
principal  may  try  to  resend  it  later  after 

//having  read  it  and  thus  taking  it's  freshenss  out... 
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int  B  =  0; 

String  placeholder  = 
while  (B  <  comp . length  0 ) 

{ 

if  ( ! comp. substring (B, B+1) . equal si gnoreCase ("*") ) 
placeholder  =  placeholder  +  comp . substring (B, B+1 ) ; 

B++ ; 

} 

comp  =  placeholder; 

//Start  the  principal  anaylsis  from  the  sender's  view 
if  (person . equals ( "sender" ) ) 

{ 

if  (Sent  nonces . contains (nonce) ) 

{ 

int  e  =  Sent  nonces . indexOf (nonce) ; 

String  old  comp  =  (String)  Sent  nonces . elementAt (e  + 

1); 

//if  ( ! comp . equalsIgnoreCase (old_comp) ) 

//  if  (temp_holdings . contains (comp)  && 
temp  holdings . contains (old  comp)  &&  comp . equalsIgnoreCase (old  comp)) 

if  (old  comp . indexOf (comp)  >  0  |  comp . indexOf (old  comp) 

>  0)  “ 

{  } 

else 

{ 

System. out . println ( "Warning :  Sender  is  transmitting 
nonce  "  +  nonce  +  "  in  two  separate  components,  invalidating  its  use  as 
an  outgoing  test."); 

Sent  nonces . removeElementAt (e  +  1); 

Sent  nonces . removeElement (nonce) ; 
nonce  =  "an  invalid  "  +  nonce; 

} 

}//End  of  if  sent  plain  has  it  and  I  am  resending  in 

another  comp 


if  (sent  plain  &&  (nonces  I_saw. contains (nonce) ) 

{ 

//since  these  nonces  are  sent  plain  I  have  to  go 
through  vector  of  invalid  test  comp 

//and  see  if  later  this  nonce  doesn't  show  up  there, 
thus  negating  it's  validity 
int  e  =  0; 

System. out . println ( "Sender  may  be  attempting  to 
initiate  an  incoming  test  by  transmitting  "  +  nonce  +  "  in  the 
clear . " ) ; 

sent  message  plain . addElement (nonce) ; 
sent  message  plain . addElement (comp) ; 

}//End  of  initiating  incoming  test 

//Start  of  initiating  outgoing  test 
else  if  ((! bad_test_comp . contains (comp)  |  t 
(temp  holdings . contains (comp) )  &&  (nonces  I  saw. contains (nonce) ) 

{//If  the  test  compopnent  is  in  bad  test  comp  and  temp 
holdings  it  can't  be  used 
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if  ( (bad_test_comp . contains (comp)  && 
temp_holdings . contains (comp) ) ) 

{  } 
else 
{ 

System. out . println ( "Sender  may  be  attempting  to 
initiate  an  outgoing  test  by  transmitting  "  +  nonce  +  "  in  encrypted 
form.  " ) ; 

Sent  nonces . addElement (nonce) ; 

Sent  nonces . addElement (comp) ; 

} 

} 

///End  of  initiating  outgoing  test 

else  if  (temp  holdings . contains (comp)  && 
bad_test_comp . contains (comp) ) 

{ 

System. out .println (comp  +  "  is  an  invalid  test 
component  because  it's  either  a  proper"); 

System. out . println ( "subterm  of  another  component  or  is 
a  duplicate  transmission!"); 

} 

else  if  (nonces  I  saw. contains (nonce)  ) 

System. out . println ( "Sender  is  attempting  to  intiate  a 
test  with  an  old/invalidated  nonce!!!"); 

if  (readable) 

{  people_I_sent_stuff_to . addElement (Ito) ;  }//Can  the 
person  I  send  it  to  read  it? 

//If  the  recipient  can't  read  it  then  it  won't  count 
later  when  checking  for  unsolicited 

if  (old_nonces . contains (nonce) ) //Stops  reuse  of  nonces 
and  won't  allow  tests  to  work 

{  int  z  =  old  nonces . indexOf (nonce) ; 
z  =  z  +  1 ; 

System. out . println (" I ' ve  sent  nonce  "  +  nonce  +  " 
out  before  in  message  "  +  old  nonces . elementAt ( z )) ; 

Sent  nonces . removeElement (old  nonces . elementAt ( z )) ;  //Get  rid  of 
message  associated  with  it 

Sent  nonces . removeElement (nonce) ; //Get  rid  of 
previously  sent  out  nonce 

if  (sent  message  plain . contains (nonce) ) 

{ 

z  =  sent  message  plain . indexOf (nonce) ; 

sent  message  plain . removeElementAt ( z  +  1); 

sent  message  plain . removeElement (nonce)  ; 

} 

} 

if  (is  fresh) / /Because  nonces  may  come  in  bundles  only  get 
the  fresh  one  for  display 
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{  the  fresh  nonce  =  nonce;  } 

else 

the  fresh  nonce  = 

if  ( ! f rom. equalsIgnoreCase  ("") ) 

{ 

String  temporary2  = 
int  h  =  0; 

while  (h  <  comp . length  0 ) 

{ 

if 

( ! comp. substring (h, h+1) .equalsIgnoreCase ("*") ) //duplicate !  See  below 
note : 

temporaryC  =  temporaryC  + 

comp. substring (h, h+1) ; //duplicate,  not  needed  but  not  sure  top  part 
will  stay 

h++;//so  not  going  to  remove  this  yet!  I  I 

} 

//comp  I  sent . addElement (temporaryC );/ /putting  comp  in 
old  vector  of  stuff  I  already  sent 
} 

//In  case  the  person  sends  out  a  nonce  both  encrypted  and 
plain  I  will  remove  them  and  announce  failed  test... 

if  (sent  message  plain . contains (nonce)  && 

Sent  nonces . contains (nonce) ) 

{ 

System. out . println ( "Sender  is  sending  the  same  nonce  " 

+  nonce  +  "  out  both  encrypted  and  plain."); 

System. out . println (" It  may  only  be  used  to  complete  an 
incoming  test."); 

//remove  the  bad  nonce  from  both  respective  vectors... 
//  int  z  =  sent  message  plain . indexOf (nonce) ; 

//  sent  message  plain . removeElementAt ( z  +  1); 

//  sent  message  plain . removeElement (nonce) ; 
int  z  =  Sent  nonces . indexOf (nonce) ; 

Sent_nonces . removeElementAt ( z  +  1); 

Sent  nonces . removeElement (nonce)  ; 

//now  we  put  this  comp  in  the  bad  test  comp  vector  so  we 
don't  flag  an  unsolicited  test 

//  bad_test_comp . addElement (comp) ; 
nonces  I_saw. addElement (nonce)  ; 

} 

}//End  of  person  being  the  sender//////////////////// 

if  (person . equals ( "receiver" ))///// /Start  the  receiver 

{ 

if  (nonces  I  saw. contains (nonce)  &&  is  fresh) 

{  System. out . println ( "Warning :  "  +  this.lname  +  "  is 
seeing  "  +  nonce  +  "  again... but  it's  tagged  with  *  (fresh) 
identifier!");  } 


if  (sent  plain  &&  is  fresh) 
nonces  I  saw. addElement (nonce) ; 
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//  && 

!bad  test  comp . contains (comp)  this  was  part  of  restrictions  on 
unsolicited  test... 

if  (! this . people  I  sent  stuff  to . contains ( from) 

&&  ! Sent  nonces . contains (nonce)  && 

!messages_I  saw. contains (comp) 

&&  readable  &&  (is_fresh  |  Iwasfresh)  && 

Inonces  I  saw. contains (nonce) 

&&  ! sent  message  plain . contains (nonce)  && 

! old_sent . contains (nonce)  &&  ! type_enc . equalsIgnoreCase ( "ASYM" ) ) 

{ 

System. out . print ( "Unsolicited  test  for  "  +  this . Iname) ; 

System. out . println ( "  because  of  nonce  "  +  nonce  +  " 
within  test  component  <  "  +  comp  +  "  >  " ) ; 

nonces  I  saw. addElement (nonce) ; 

}//End  of  If  for  unsolicited  test 

else  if  (! this . people  I  sent  stuff  to . contains ( from)  && 
! bad_test_comp . contains (comp) 

&&  !messages_I_saw. contains (comp)  &&  readable  && 
is  fresh  &&  (nonces  I  saw. contains (nonce) 

I  sent  message  plain . contains (nonce)  | 

Sent_nonces . contains (nonce) ) ) 

{  System. out . println ( "Sender  may  be  attempting  to 
initiate  a  test  with  an  old  nonce!");  } 


else  if  ( I  this . people  I  sent  stuff 
bad_test_comp . contains (comp)  && 

(messages  I  saw. contains (comp) 


is  fresh) 


{ 


to. contains (from) 
&&  readable  && 


System. out . print ( "Receiver  is  receiving  an  invalid 
test  component  "  +  comp) ; 

System. out . println ( "  otherwise,  it  would  be  an 
unsolicited  test  with  fresh  term  "  +  nonce) ; 


} 


&& 


if  (this. people  I  sent  stuff  to . contains ( from)  && 
readable  &&  is  fresh 

&&  inonces  I  saw. contains (nonce)  && 

I  Sent  nonces . contains (nonce) 

&&  I  sent  message  plain . contains  (nonce)  && 

I old_sent . contains (nonce)  &&  I type_enc . equalsIgnoreCase ( "ASYM" ) ) 

{ 

System. out . println ( "Pseudo-unsolicited  test  for  "+ 
this. Iname  +  "  because  "  +  nonce 

+  "  is  a  newly  received  fresh  nonce,  but  "  + 
this. Iname  +  "  has  sent  items  to  "  +  from  +  "  previously."); 

nonces  I_saw. addElement (nonce) ; 

} 

else  if  (this .people_I  sent  stuff  to . contains ( from)  && 
readable  &&  is  fresh 

&&  inonces  I  saw. contains (nonce)  && 

Sent  nonces . contains (nonce) ) 
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{  System. out . println ( "Sender  may  be  attempting  to 
intitiate  a  test  with  an  old  nonce!");  } 


if  (comp  I  sent . contains (comp)  &&  I  sent  plain) 

System. out . println ( "Evaluation  of  term  "  +  nonce  + 
"  indicates  it  is  part  of  a  component  "  +  comp) ; 

System. out . println ( "which  is  being  retransmitted. 
Therefore,  test  component  "  +  comp  +  "  is  invalidated!"); 

} 


if  ( ! comp  I  sent . contains (comp)  && 

!old  nonces . contains (nonce) ) 

{//If  it  is  fresh  and  not  a  duplicate  test  comp  and  not 
a  proper  subterm  somewhere 

if  (Sent  nonces . contains (nonce)  &&  sent  plain) 

{ 

int  t  =  Sent  nonces . indexOf (nonce) ; 

t=t+l; 

System. out . println ( "The  encrypted/f resh  nonce  "  + 
nonce  +  "  has  been  received  back  in  new  component:  "  +  comp); 

System. out . print ( "Outgoing  test  for  "  +  this.lname  + 
"  because  fresh  term  "  +  nonce  +  "  was  sent  out  earlier"); 

System. out . println ( "  in<"+ 

Sent_nonces . elementAt (t) +  "  >  "); 

old  nonces . addElement (nonce) ; //Now  I've  got  it  back 
I  add  nonce  to  old  nonces  vector 


old_nonces . addElement (Sent_nonces . elementAt (t) ) ; //add  associated 
message 

} 

if  (sent  message  plain . contains (nonce)  &&  ! sent  plain 

&& 


! (bad_test_comp . contains (comp)  && 

temp_holdings . contains (comp) ) &&  ! type  enc . equalsIgnoreCase ( "ASYM" ) ) 

{ 

int  t  =  sent  message  plain . indexOf (nonce) ; 
t  =  t  +  1  ; 

System. out . println ( "The  unencrypted/ fresh 
nonce  "  +  nonce  +  "  has  been  received  back  in  new  component:  "  +  comp); 

System. out . print (" Incoming  test  for  "  +  this.lname  + 
"  because  fresh  term  "  +  nonce  +  "  was  sent  out  earlier"); 

System. out . println ( "  in  <  "  + 
sent  message  plain . elementAt (t)  +  "  >"); 

old  nonces . addElement (nonce) ; 


old  nonces . addElement ( sent  message  plain . elementAt (t) ) ; 

}//End  of  else  for  incoming 

if  (Sent  nonces . contains (nonce)  &&  ! sent  plain  && 

! temp_holdings . contains (temp  comp) &&  type  enc . equalsIgnoreCase ( "ASYM" ) ) 

{ 

int  t  =  Sent  nonces . indexOf (nonce) ; 
t  =  t  +  1 ; 
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System. out . println ( "The  encrypted/f resh  nonce  "  + 
nonce  +  "  has  been  received  back  in  new  component:  "  +  comp); 

System. out . print ( "Outgoing  test  for  "  +  this.lname  + 
"  because  fresh  term  "  +  nonce  +  "  was  sent  out  earlier"); 

System. out . println ( "  in  <  "  + 

Sent  nonces . elementAt (t) +  "  >  "); 

old  nonces . addElement (nonce) ; //Now  I've  got  it  back 
I  add  nonce  to  old  nonces  vector 

old_nonces . addElement ( Sent_nonces . elementAt ( t ) ) ; / /add  associated 
message 

}//End  of  else  if  for  outgoing  test 

else  if  (Sent  nonces . contains (nonce)  &&  (sent  plain 
&&  ! temp  holdings . contains (temp  comp)) 

{ 

int  t  =  Sent  nonces . indexOf (nonce) ; 
t  =  t  +  l; 

System. out . println ( "The  encrypted/f resh  nonce  "  + 
nonce  +  "  has  been  received  back  in  new  component:  "  +  comp); 

System. out . print ( "Outgoing/ Incoming  test  for  "  + 
this.lname  +  "  because  fresh  term  "  +  nonce  +  "  was  sent  out  earlier"); 

System. out . println ( "  in  <  "  + 

Sent  nonces . elementAt (t) +  "  >  "); 

old  nonces . addElement (nonce) ; //Now  I've  got  it  back 
I  add  nonce  to  old  nonces  vector 

old_nonces . addElement ( Sent_nonces . elementAt ( t ) ) ; / /add  associated 
message 

}//End  of  else  if  for  outgoing/incoming  test 

if  (temp  holdings . contains (temp  comp)  && 

Sent_nonces . contains (nonce) ) 

{ 

System. out . println ( "The  encrypted  nonce  "+  nonce  + 

"  has  been  received  back,  but  in  a  duplicated  transmission!"); 

System. out . println ( "The  component  "  +  comp  +  "  was 
sent  out  identically  by  this  sender."); 

}//End  of  retransmitted  test 

} 

}//End  of  receiver  part  of  addnonce  function 
}  //End  of  addnonce 
}//End  of  class  Principal 
package  protocolB; 

/  *  * 

*  Stephen  Mancini  and  Robert  Graham 

*  AFIT/ENG 

*  23  Feb  2004 

The  purpose  of  this  class  is  as  follows: 

Whenever  an  instance  of  an  encrypted  term  is  called,  it  happens  here. 
This  class  will  ascertain  if 

a  particular  message  is  readable  by  sender,  receiver,  both  or  neither. 
This  happens  through  recursive  calls 

of  getreadabletext ( )  which  is  abstract  and  located  several  classes. 

The  arguments  are  the  same,  however,  based 
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on  who  can  read  it,  the  from  and  to  strings  are  set  to  relevant 
setting.  For  instance,  if  a  sender  can  read  it 
the  from  string  is  set  to  that  value. 

Bottom  line,  based  on  key  values,  sender  and  receiver  are  set  and 
getreadabletext  function  is  called... 

*/ 

import  j ava . util . * ; 

public  class  Encryption  extends  Term 

{ 

/**  Creates  a  new  instance  of  Encryption  */ 
public  Encryption (Term  t.  Text  k)  { 
this. term  =  t; 
this. key  =  k; 

} 

public  Term  getTermO  { 
return  term; 

} 

public  Text  getKeyO  { 
return  key; 

} 


public  void  getComp (Vector  bad  test  comp.  Vector  temp  holdings. 
String  Ifrom,  String  Ito,  boolean  outside) 

{//I  only  want  to  add  those  cases  where  t  =  {h}k  so  add  encrypted 
wihtin  encrypted  components ! 

if  (outside) 

{ 

//This  part  is  for  whenever  I  might  be  bringing  encryption  from 
the  min  part  but  lets  say  it  is  in  a  sequence 

//I  still  need  to  store  that  outside  part  and  unfortunately 
this  can't  be  done  in  PA  because  it  call  getComp 

//of  whatever  object  type  it  finds.  So  if  outside  is  only 
encryption  I  can  handle  it  in  PA  otherwise  I  go  inside 

//each  object  type's  getComp  and  do  whatever,  in  some  cases 
this  misght  perform  different  functions 

//so  you  may  see  repeating  code  ut  chances  are  it  is  augmenting 
something  unique  to  that  inside  instance 
temp  holdings . addElement (this) ; 
int  max  =  this . toString (). length () ; 
int  Y  =  0; 

String  hold  = 
while  (Y  <  max) 

{ 

if  (! this . toString (). substring (Y,  Y+1 ) . equalsIgnoreCase ( " * " ) ) 
hold  =  hold  +  this . toString (). substring (Y,  Y+1); 

Y++; 

}//End  of  while  loop  through  string 
temp  holdings . addElement (hold) ; 

String  holdl  =  hold  +  Ifrom; 

String  hold2  =  hold  +  Ito; 
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if  ( ! temp  holdings . contains (holdl )  ) 
if  ( ! temp  holdings . contains (hold2 ) ) 

temp  holdings . addElement (holdl ) ; 

}//End  of  adding  component  based  on  the  fact  that  it  is  outside 
but  iin  sequential  order 

if  (this . getTerm ( )  instanceof  Sequence) 

{ 

Sequence  S  =  (Sequence)  this . getTerm () ; 

for  (Listiterator  k  =  S . getTerms ( ) ;  k . hasNext  ( ) ; ) 

{ 

Term  1  =  (Term)  k.nextO; 
if  (1  instanceof  Encryption) 

{//Not  seeing  the  other  term  as  encryption... 
if  (temp  holdings . contains ( 1 . toString 0) ) 

bad  test  comp . addElement ( 1 );/ /encryption  within 
encryption ...  ruled  out  as  test  component 

////////////// /Just  removing  any  astrerisks 
int  max  =  1 . toString (). length ()  ; 
int  Y  =  0; 

String  hold  = 
while  (Y  <  max) 

{ 

if  (! 1 . toString (). substring (Y, 

Y+1 ) . equals I gnoreCase ( " * " ) ) 

hold  =  hold  +  1 . toString (). substring (Y,  Y+1); 

Y++; 

} 

bad  test  comp . addElement (hold)  ; 

//////////// /End  of  removing  any  asterisks 

1 . getComp (bad_test  comp, temp  holdings,  Ifrom,  Ito, 
false) ; //Make  sure  their  isn't  more  encryption  within 
} 

else 

{//not  encrSyption?  Then  either  more  sequence  or  text!  Love 
abstract  classes. 

1 . getComp (bad  test  comp,  temp  holdings , If rom,  Ito,  false); 

} 

}//End  of  for  loop  through  sequence  iterator 
}//End  of  if  it's  a  sequence.. if  not  sequence  or  encryption  don't 
worry  about  it,  it  must  be  text  only. 

else  if  (this . getTerm ( )  instanceof  Encryption) / /encryption  within 
encryption 

{//Any  encrypted  components  wihthin  encrypted  components  are 
ruled  out  as  test  components 

if  (temp  holdings . contains (this . getTerm (). toString 0) ) 
bad  test  comp . addElement (this . getTerm ()) ; 

} 

}//end  of  getComp 0  function 
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public  void  getTextObj (Vector  text_ob j ) 

{//Let  us  get  all  the  text  objects  that  are  within  encryped  terms 
if  (this . getTerm ( )  instanceof  Sequence) 

{ 

Sequence  s  =  (Sequence)  this . getTerm () ; 

for  (Listiterator  i  =  s . getTerms ( ) ;  i . hasNext  ( ) ;  ) 

{ 

Term  u  =  (Term)  i.nextO; 
u. getTextObj (text_obj) ; 

} 

}//end  of  sequence 

else  if  (this . getTerm ( )  instanceof  Text) 
this . getTerm ( ) . getTextObj (text_obj ) ; 
else 

this . getTerm ( ) . getTextObj (text_obj ) ; 

}//End  of  getTextObj  0 


public  void  getReadableTexts ( String  Ifrom,  String  Ito,  Vector  p, 
boolean  readable, 

boolean  sent  plain.  String  comp. 

Vector  list  of  components. 

Vector  old_sent.  Vector  bad_test_comp. 
Vector  temp_holdings ,  Vector  text_ob j ,  String  type_enc) 

{ 

String  temp  =  "";//If  I  can't  open  it  I  need  to  send  a  blank 
recipient 

String  temp  from  =  "";//!  will  set  this  based  on  whether  or  not 
component  is  new  regardless  of  encryption 

//Making  assumotion  that  if  comp  is  new  that  is  where  it 
originates . 

String  tempi  =  this . key . toString (). substring ( 1 , 2 );/ /Set  the  first 
value  for  the  key 

String  temp2  =  //Maybe  there  are  2  values  for  the  key... 

type  enc  =  "ASYM";  //What  type  of  encryption?  Needed  for 
negating  unsolicited  tests 

if  (comp . equalsIgnoreCase ( " " ) ) 

comp  =  this . term. toString 0; //If  it  wasn't  a  sequence  in 
P..A...  then  just  use  this  term 

if  (this . key . toString ( ) .length()>2) 

{ 

temp2  =  this . key . toString (). substring (2 , 3 ) ; 
type  enc  =  "SYM"; 

} 

if  (llist  of  components . contains (comp) ) 

{ 

temp_from  =  ifrom; 

list  of  components . addElement (comp) ; //It ' s  not  getting  added  in 
PA  so  this  is  a  quick  fix. . . 
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//besides,  most  concern  in  protocols  comes  inside  the  encrypted 
portions  transmission. 

} 

if  ( (tempi . equalsIgnoreCase (Ito)  |  temp2 . equalsIgnoreCase (Ito) ) 

&&  (tempi .equalsIgnoreCase (Ifrom)  |  temp2 . equalsIgnoreCase (Ifrom) ) ) 
{//sender  and  recipient  can  read  it 

System. out . println ( "Encrypt  term(s)  <  "  +  this. term  +  "  >  with 
key  "  +  this . getKey ( ) .toStringO  +  "  is  readable  by  both 
sender/receiver . "  ) ; 

term. getReadableTexts (Ifrom,  Ito,  p,  true,  false,  comp, 
list  of  components,  old  sent,  bad  test  comp,  temp  holdings,  text_ob j , 
type_enc) ; //  this . term. toString ( ) ) ; 

} 

else  if  (tempi .equalsIgnoreCase (Ito)  | 
temp2 .equalsIgnoreCase (Ito) ) 

{//Only  the  recipient  can  read  it 

System. out . println ( "Encrypted  term(s)  <  "  +  this. term  +  "  >  with 
key  "  +  this . getKey (). toString ( )  +"  is  readable  by  recipient  only."  ) ; 

term. getReadableTexts (temp  from,  Ito,  p,  true,  false, comp, 
list  of  components,  old  sent,  bad  test  comp,  temp  holdings,  text  ob j , 
type_enc) ; //  this . term. toString ( ) ) ; 

} 

else  if  (tempi . equalsIgnoreCase (Ifrom)  | 
temp2 .equalsIgnoreCase (Ifrom) ) 

{//Only  the  sender  can  read  it 

System. out . println ( "Encrypted  term(s)  <  "  +  this. term  +  "  >  with 
key  "  +  this . getKey ( ) .toStringO  +  "  is  readable  by  sender  only."); 

term. getReadableTexts (Ifrom,  temp,  p,  false,  false, comp, 
list  of  components,  old  sent,  bad  test  comp,  temp  holdings,  text  ob j , 
type_enc) ; //  this . term. toString ( ) ) ; 

} 

else 

{//Neither  can  read  it 

System. out . println ( "Encrypted  term(s)  <  "  +  this. term  +  "  > 
with  key  "  +  this . getKey ( ) .toStringO  +  "  is  readable  by  neither  sender 
nor  receiver."); 

term. getReadableTexts (temp  from,  temp,  p,  true,  false,  comp, 
list  of  components,  old  sent,  bad  test  comp,  temp  holdings,  text  ob j , 
type_enc) ; //If  the  key  doen't  match  either  party 
} 

} 

public  String  toStringO  { 

return  "{"  +  term. toString ()  +  +  key . toString () ; 

} 

protected  Term  term; 

protected  Text  key; 

protected  boolean  within  =  false; 

} 

package  protocolB; 

/  *  * 
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* 

*  A  Protocol  is  a  sequence  of  {@link;  Message}s. 

*  Created  on  December  8,  2003,  4:57  PM 

*  @author  rgraham 
*/ 

import  j ava . util . * ; 
public  class  Protocol 
{ 

/**  Creates  a  new  instance  of  a  Protocol.  */ 
public  Protocol  0  { 

messages  =  new  ArrayList ( )  ; 

} 

public  void  addMessage (Message  m)  { 
messages . add (m) ; 

} 

public  Listiterator  listiterator ( )  { 

return  messages . listiterator ()  ; 

} 

public  String  toStringO  { 

StringBuffer  sb  =  new  StringBuf f er ( ) ; 

for  (Listiterator  i  =  messages . listiterator () ;  i.hasNextO 
sb . append (( (Message)  i . next ( ) ) . toString ( )  +  "\n"); 

return  sb . toString () ; 

} 

protected  List  messages; 

private  static  class  Classl  { 

} 


package  protocolB; 

/  *  * 

*  A  message  is  a  term  that  one  principal  sends  to  another. 

* 

*  @author  rgraham 

*/ 

public  class  Message  { 

/**  Creates  a  new  instance  of  Message  */ 

public  Message ( String  from.  String  to.  Term  term)  { 
this. from  =  from; 
this. to  =  to; 
this. term  =  term; 

} 

public  String  getReceiver ( )  { 

return  to; 

} 
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public  String  getSenderO  { 
return  from; 

} 

public  Term  getTermO  { 
return  term; 

} 

public  void  setReceiver ( String  to)  { 
this. to  =  to; 

} 

public  void  setSender ( String  from)  { 
this. from  =  from; 

} 

public  void  setTerm(Term  term)  { 
this. term  =  term; 

} 

public  String  toStringO  { 

return  from  +  "  ->  "  +  to  +  "  :  "  +  term; 

} 

protected  String  from; 
protected  Term  term; 
protected  String  to; 

} 

/* 

*  TermParser . j ava 

* 

*  Created  on  December  8,  2003 
*/ 

package  protocolB; 

import  protocolB . Parser .* ; 
import  java.io.*; 

import  j  ava . text . ParseException; 

/  *  * 

*  A  TermParser  tests  the  parser's  ability  to  parse  Terms.  The  term  to 
parse  is 

*  specified  on  the  command  line  (if  it  contains  space,  put  it  in 
quotes) . 

* 

*  @author  rgraham 
*/ 

public  class  TermParser 

{ 

public  static  void  main ( String [ ]  args)  { 
boolean  err  =  false; 

Term  term  =  null; 
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} 


if  (args. length  ==  0)  { 

System. out . println ( "Nothing  to  parse."); 

System. exit  ( 1 ) ; 

} 

System. out . println ( "Parsing  term:  +  args[0]  + 

Parser  p  =  new  Parser (new  StringReader (args [0]  )  )  ; 
try  { 

term  =  p . parseTerm ( ) ; 

}  catch  ( ParseException  e)  { 

System. out .println (e  +  "  at  offset  "  +  e . getErrorOf f set ( ) ) 
err  =  true; 

}  catch  (Exception  e)  { 

System. out .println (e)  ; 
err  =  true; 

} 

if  ( ! err) 

System. out . println ( "Successful  parse  of  +  term  +  "'"); 
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